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EXECUTIVE  SUMMARY 


With  the  advent  of  the  Water  Resources  Development  Act  of  1989,  the  Corps 
entered  into  a  new  era  in  cost  sharing  and  project  management.  The  Corps 
embarked  on  the  life  cycle  management  of  its  projects  and  the  need  to  report  the 
status  of  its  activities  under  a  management  effort  entitled  "Initiative  88.”  In 
recognition  of  the  fact  that  current  project  management  tools  are  not  adequate  to 
provide  the  needed  information  in  the  proper  form  within  the  prescribed  time 
frame,  the  Corps  is  modernizing  its  computer-aided  project  management  information 
capabilities. 

The  effort  reported  herein  explores  whether  commercially  available  software 
can  be  used  to  meet  the  Corps’  immediate  and  long-term  needs,  lists  the  criteria 
used  in  evaluating  the  software,  gives  impressions  of  the  studied  software,  and  gives 
recommendations  for  implementation.  The  primary  objective  was  not  to  recommend 
a  system(s)  that  would  meet  the  Corps’  needs,  but  to  conclude  only  whether  or  not 
any  candidate  system(s)  exists. 

The  approach  used  was: 

a.  Survey  available  information  and  previous  studies. 

b.  Define  the  requirements  and  establish  criteria. 

c.  Survey  commercially  available  systems. 

d.  Match  criteria  developed  with  capabilities  of  existing  systems. 

e.  Recommend  solutions. 

The  study  was  conducted  using  a  field  task  group  approach  to  bring  balance  and 
realism  to  the  conclusions  and  recommendations. 

The  task  group  addressed  three  requirements  in  developing  the  criteria.  These 
arc:  scheduling  and  reporting  requirements  mandated  with  the  implementation  of 
Life  Cycle  Project  Management  (LCPM),  scheduling  and  repotting  icquirements 
currently  mandated  by  the  Corps,  and  internal  field  operating  agency  (FOA) 
management  scheduling  and  icporliug  weeds.  Tit^  concluded  that  project 
management  system  software  that  will  meet  the  requirements  should  consist  of  a 
project  scheduling  component  and  a  project  control  component  with  appropriate 
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capabilities  in  networking,  reporting,  resource  handling,  and  interfacing.  They 
selected  six  products  as  candidates  for  review  and  visited  the  vendor  facilities. 

Conclusions  and  recommendations  are  provided  below: 

Conclusions 

a.  Software  products  exist  in  the  commercial  market  that  could  be  used 
to  satisfy  LCPM  at  all  levels  of  management. 

b.  LCPM  requirements  at  the  District,  Division,  and  HQUSACE  levels 
can  be  satisfied  by  providing  report  extracts  from  the  IPM/TPM  micro  systems. 

c.  A  micro-based  project  management  system  consisting  of  a  project 
scheduler  and  a  DBMS  must  be  identified  as  part  of  a  recommended  system  to  be 
used  by  the  IPM/TPM. 


Recommendations 

a.  Select  a  project  networking  system  that  would  complement  the  data 
collection  requirement  for  use  by  the  IPM/TPM. 

b.  Standardize  the  database  structures  from  USACE  to  the  district  LCPM 

level. 

c.  Develop  a  standard  work  break  down  structure  (WBS)  and  an 
organizational  break  down  structure  (OBS). 

d.  Acquire  (or  continue  developing)  a  new  F&A  system  that  meets  the 
needs  of  not  only  the  Comptroller  but  also  managers  of  projects  and  resources. 

c.  Establish  a  Center  for  Computer-Aided  Project  Management  (CCAPM) 
in  the  Corps  similar  to  the  Computer-Aided  Design  and  Drafting  (CADD)  Center 
at  the  Waterways  Experiment  Station.  The  Center,  like  the  CADD  Center,  should 
be  field-driven  and  should  become  the  focal  point  for  fostering  project  management 
activities  in  the  Corps.  The  Center  will  be  a  facilitator  tor  the  HO  Program 
Manager  for  LCPM. 
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f.  During  CEAP  pilot  testing  consider  the  impact  of  CEAP  and  the 
redesigned  F&A  system  on  the  recommendations. 

g.  An  implementation  strategy  using  commercially  available  software  and 
an  interfaced  approach  is  recommended.  Under  this  strategy  data  at  all  levels  of 
management  will  be  kept  at  a  manageable  level.  The  definition  of  data  required  for 
management  at  HQUSACE  must  be  defined  first  so  that  subordinate  offices  can 
define  their  data  requirements. 
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PREFACE 


This  report  investigates  the  availability  of  commercial  software  for  the  Corps 
of  Engineers’  Life  Cycle  Project  Management  (LCPM).  The  tasking  was  from 
Mr.  John  Wallace,  Chief,  Resource  Management  Office,  and  a  member  of  the 
Headquarters  Information  Resource  Management  Executive  Committee,  to 
Dr.  N.  Radhakrishnan,  Chief,  Information  Technology  Laboratory  (ITL),  US  Army 
Engineer  Waterways  Experiment  Station  (USAEWES).  The  work  was  performed 
from  15  Jan  1989  through  31  Mar  1989. 

Dr.  N.  Radhakrishnan  was  Project  Manager  for  the  task.  Mr.  Warren  Bennett, 
USAEWES,  served  as  the  Project  Coordinator  and  Leader.  The  study  was 
conducted  using  a  field  task  group  approach  with  Mr.  Bob  Hughey,  Chief,  Design 
Branch,  serving  as  Chairman  of  the  task  group.  The  following  members  constituted 
the  task  group: 

Mr.  Bob  Hughey,  CELMS-ED-D,  Chairman 

Dr.  Ed  Middleton,  CEWES-IM-D,  Co-Chairman 

Dr.  N.  Radhakrishnan,  CEWES-IM-Z,  Project  Manager 

Mr.  Warren  Bennett,  CEWES-IM-CD-C,  Project  Coordinator 

Mr.  Darrell  Alverson,  CESWD-ED 

Mr.  James  Goering,  CEMRK-ED 

Mr.  Moon-Yong  Han,  CENPD-EN 

Mr.  Rodney  Metzger,  CEEC-CA 

Mr.  Jack  Neimi,  CELMS-DP 

CPT  Richard  Thompson,  CENCC-CO-A 

Assistance  of  the  task  group  members  is  gratefully  acknowledged. 

An  In-Progress  Review  was  provided  to  the  Executive  Committee  in  March 
1989.  Dr.  Radhakrishnan,  Mr.  Bennett,  Mr.  Hughey,  Mr.  Mctzer,  and 
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CPT  Thompson  visited  the  vendor  sites,  7-10  March,  to  view  the  products.  This 
report  was  written  by  Dr.  Radhakrishnan,  Mr.  Bennett,  and  Mr.  Hughey. 

During  the  course  of  this  study,  the  team  talked  with  a  number  of  people  in 
Corps  offices  and  outside  the  Corps.  Particular  thanks  are  due  to 
Messrs.  Bob  Thomas  and  David  Pence,  Engineer  Automation  Support  Agency, 
Ms.  Bobbi  Schwendig  and  staff,  Idaho  National  Engineering  Laboratory,  and 
Messrs.  William  Moore  and  Jeffrey  Hawkins,  Logistics  Management  Institute.  The 
support  extended  by  Mr.  Wallace  and  COL  Patrick  Kenny,  Director  of  Information 
Management,  is  gratefully  acknowledged.  Ms.  Jamie  Leach,  ITL,  edited  this 
document;  Mses.  Sandy  Lewis,  Martha  Pettway,  Linda  McGowan,  and  Janet  Kelley 
typed  this  document.  Their  assistance  under  tight  time  constraints  is  greatly 
appreciated. 

The  work  was  done  in  the  period  January-March  1989.  Commander  and 
Director  at  WES  was  COL  Dwayne  G.  Lee,  EN,  and  Technical  Director  was 
Dr.  Robert  W.  Whalin. 
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Study  on  the  Availability  of  Commercial  Software  for  the 
Corps’  Life  Cycle  Project  Management  (LCPM) 


I.  Introduction 

1.  With  the  advent  of  the  Water  Resources  Development  Act  of  1989,  the 
Corps  entered  into  a  new  era  in  cost  sharing  and  project  management.  The  Corps 
embarked  on  the  life  cycle  management  of  its  projects  and  reporting  the  status  of 
its  activities  under  a  management  effort  entitled  "Initiative  88."  The  reporting 
requirements  of  both  Initiative  88  and  other  mandatory  data  items  the  Corps  needs 
to  accomplish  its  work  are  detailed  in  EC  1110-2-536  (30  Jun  88).  In  recognition 
of  the  fact  that  the  old  project  management  tools  are  not  adequate  to  provide  the 
needed  information  in  the  proper  form  within  the  prescribed  time  frame,  the  Corps 
is  proceeding  along  several  fronts  to  modernize  its  computer-aided  project 
management  information  capabilities.  For  example,  a  group  of  senior  Corps 
personnel  met  in  January  -  February  1989  and  developed  a  Structured  Requirements 
Analysis  Plan  (STRAP).  A  second  group  surveyed  the  field  offices  to  determine 
what  software  is  currently  being  used  in  support  of  the  LCPM.  This  survey  found 
that  a  variety  of  commercial  software  is  being  used  in  the  field  with  mixed  levels  of 
satisfaction. 

2.  The  effort  reported  herein  explores  whether  commercially  available  software 
can  be  used  to  meet  the  Corps’  immediate  and  long-term  LCPM  needs.  The  task 
was  assigned  by  Mr.  John  Wallace,  Chief,  RMO,  HQUSACE,  and  a  member  of  the 
Corps’  IRM  Steering  Committee,  to  Dr.  N.  Radhakrishnan,  Chief,  Information 
Technology  Laboratory,  USAEWES,  in  mid-December  1988.  A  team  of  Corps 
personnel  under  the  leadership  of  Bob  Hughey,  St.  Louis  District,  assisted  in 
developing  the  necessary  criteria  and  evaluating  commercially  available  software. 
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3.  This  report  contains  criteria  used  in  evaluating  the  software,  impressions  of 
the  studied  software,  recommendations  for  implementation  of  LCPM,  and  some  Held 
views  on  operation  of  LCPM.  A  list  of  definitions  of  terms  used  in  this  report  is 
provided  in  Appendix  A. 
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II.  Scope  and  Objectives 


4.  The  principal  objective  of  this  study  was  to  determine  whether  any 
commercial  software  system(s)  is  (are)  available  that  would  meet  most,  if  not  all,  of 
the  Corps’  needs  for  LCPM.  LCPM,  as  defined  in  EC  1110-2-536  (30  Jun  88),  is 
the  reference  criteria  for  this  study.  Additional  information  was  acquired  throughout 
the  study  from  Corps  personnel.  As  defined  in  the  EC,  LCPM  begins  with  the 
assignment  of  a  project  manager  and  continues  to  the  end  of  the  Corps’  interest  in 
the  project. 

5.  Further  objectives  of  this  study  were:  (a)  if  there  is  (are)  commercial 
systems  available,  can  they  be  used  off-the-shelf,  or  do  they  need  to  be  modified  to 
fit  the  Corps’  needs,  and  (b)  if  there  are  no  commercial  systems  available,  what  is 
so  unique  about  the  Corps’  requirements  in  comparison  with  the  private  sector 
requirements?  It  should  be  emphasized  that  the  primary  objective  was  not  to 
recommend  a  system(s)  that  would  meet  the  Corps’  needs,  but  to  conclude  only 
whether  or  not  any  candidate  system(s)  exist. 

6.  Although  the  original  task  included  field  testing  of  a  software  package,  this 
requirement  was  eliminated  due  to  time  limitations  and  procurement  considerations. 
The  field  testing  would  have  added  very  little  to  the  study  and  would  have  been 
difficult  to  perform  within  the  time  constraints  (less  than  75  days).  Realistic  field 
testing  would  have  necessitated  the  simulation  of  a  life  cycle  of  a  project,  training 
of  project  engineers  and  managers  on  the  software,  implementation  of  the  system 
with  interfaces  to  several  existing  Corps  stove-pipe  systems,  and  performance  of 
other  time-consuming  tasks.  Instead,  vendor  demonstration  of  products  based  on 
a  scenario  worked  out  by  the  task  group  was  substituted  for  field  testing.  These 
demos  were  attended  by  engineers  who  were  representatives  of  end  users,  middle 
level  managers,  and  other  raw  data  providers  to  the  LCPM  system. 
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III.  Study  Approach 


7.  The  approach  used  in  this  study  to  achieve  the  objectives  consisted  of  the 
following  steps: 

a.  Survey  information  and  studies  available  in  the  Corps  and  elsewhere  on 

LCPM. 

b.  Define  requirements  and  establish  broad  functional  and  technical 

criteria. 

c.  Survey  commercial  systems  available  in  the  market. 

d.  Match  criteria  developed  in  (a)  with  capabilities  of  systems  and  develop 
a  short  list  of  systems: 

(i)  Develop  a  scenario  for  vendors  to  demonstrate  their  systems  and 
observe  the  systems  in  action. 

(ii)  Augment  the  demos  with  experience  from  people  who  have  used 
these  systems. 

e.  Conclude  and  recommend  solutions  for  both  the  interim  as  well  as  the 
long-term  needs  of  the  Corps. 

8.  The  study  was  conducted  using  a  field  task  group  approach  to  bring  balance 
and  realism  to  the  conclusions  and  recommendations. 

9.  An  overview  of  this  approach  is  provided  below: 

a.  Survey  Information  and  Studies  Available  in  the  Corps  and  Elsewhere 
on  LCPM  -  The  team  reviewed  a  number  of  studies  and  literature  available  in 
publications  and  vendor  provided  bulletins.  Studies  included  those  by  LMVD,  NCD, 
SAM,  SPS,  EASA,  CERL,  and  NASA  in  addition  to  HQ  provided  information  such 
as  EC  1110-2-536,  Private  Sector  Study,  LCPM  STRAP,  etc. 

b.  Broad  Criteria  Development  -  There  were  no  published  criteria  available 
for  performing  LCPM  in  an  operational  environment  in  a  district  office.  The 
criteria  had  to  be  defined  before  the  researchers  could  embark  on  finding  a 
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commercial  system  to  meet  the  Corps’  needs.  Mr.  Bob  Hughey,  Chief,  Design 
Branch,  St.  Louis  District,  served  as  chairman  of  the  following  group  tasked  to 
develop  the  criteria: 

Mr.  Bob  Hughey,  CELMS-ED-D,  Chairman 
Dr.  Ed  Middleton,  CEWES-IM-D,  Co-Chairman 
Mr.  Darrell  Alverson,  CESWD-ED 

Mr.  Warren  Bennett,  CEWES-IM-CD-C,  Project  Coordinator 

Mr.  James  Goering,  CEMRK-ED 

Mr.  Moon-Yong  Han,  CENPD-EN 

Mr.  Rodney  Metzger,  CEEC-CA 

Mr.  Jack  Neimi,  CELMS-DP 

CPT  Richard  Thompson,  CENCC-CO-A 

Dr.  N.  Radhakrishnan,  CEWES-IM-Z,  Project  Manager 

The  task  group  was  formed  with  the  belief  that,  for  a  system  to  be  successfully 
fielded,  "end  users"  of  the  system  and  middle  level  managers  must  play  a  strong  role 
in  defining  the  criteria  for  both  upward  reporting  and  local  project  management. 
Since  engineers  from  district  offices  will  be  the  primary  contributors  of  data  to  a 
LCPM  system,  they  should  be  involved  in  defining  the  criteria.  The  emphasis  was 
on  developing  broad  criteria  in  contrast  to  a  STRAP  process  (which  is  more  detailed 
with  the  development  of  data  models).  Since  the  study  concentrated  only  on 
ascertaining  the  feasibility  of  using  commercial  products,  this  scope  was  deemed 
appropriate. 

c.  Survey  Commercial  Systems  Available  in  the  Market  -  There  are  over 
150  project  management  software  packages  available  on  the  market.  Many  of  them 
run  only  on  microcomputers.  The  task  group  predominantly  looked  at  systems  that 
run  on  a  range  of  platforms  including  microcomputers,  minicomputers,  and 
mainframes.  This  reduced  the  list  considerably. 

d.  Matching  Criteria  and  Capabilities  -  The  team  compared  the  capabilities 
of  the  "short  list"  systems  against  the  criteria  established.  A  scenario  was  developed 
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for  the  vendors  to  use  during  their  demonstration  sessions.  Further,  the  experience 
that  Corps  FOAs  had  in  using  some  of  these  systems  was  also  taken  into  account. 
Six  vendors  were  visited  by  a  select  subgroup  of  the  task  group. 


e.  Conclusions  and  Recommendations  -  Findings,  conclusions,  and 
recommendations  were  determined  by  carefully  analyzing  the  results  and  applying 
a  set  of  assumptions  regarding  the  Corps'  present  and  projected  hardware  and 
software  environments. 
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IV.  Literature  Research 


10.  Recent  research  efforts  to  develop  criteria  for  project  management  systems 
revealed  several  applicable  studies.  A  study  by  NASA  completed  in  September  1988 
was  of  particular  interest.  The  NASA  Stennis  Space  Center  was  in  need  of  a  Con¬ 
struction  Management  Information  System  and  contracted  with  Battelle  Corporation 
to  perform  the  study.  Criteria  were  developed,  and  systems  surveys  were  performed. 
This  is  very  similar  to  the  approach  taken  in  the  present  study.  The  Corps  task 
group  reviewed  the  NASA  study  prior  to  developing  the  functional  criteria. 

11.  The  "Life  Cycle  Project  Management  Off-the-Shelf  Software  Survey" 
published  by  D/IM,  2  February  1989,  itemized  the  efforts  in  the  Corps  to  satisfy 
LCPM  with  available  software  and  resources.  The  implementations  varied  from 
district  to  district  but  all  attempted  to  derive  a  toolbox  for  the  LCPM  Individual 
Project  Manager  (IPM)/Team  Project  Manager  (TPM)  that  satisfied  the  total 
requirement  to  varying  extents. 

12.  EC  1110-2-536  and  the  LCPM  STRAP  report  provided  the  total  LCPM 
direction  and  the  HQ  viewpoint  of  LCPM.  The  task  group  was  thoroughly  familiar 
with  the  EC  prior  to  convening. 

13.  Additional  publications  and  journals  were  reviewed  to  obtain  the  industry 
and  theoretical  perspective.  These  included  reports  from  CERL,  the  Private  Sector 
Council  study,  books  on  project  management  by  Kerzner  and  Moder,  and  articles 
from  technical  publications.  A  complete  list  of  references  is  provided  in 
Appendix  B. 
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V.  Criteria  Development 


Construction  Management  by  the  Corps  of  Engineers 

14.  The  Corps  of  Engineers  administers  construction  contracts.  The  Corps 
does  not  bid,  prepare  detailed  construction  schedules,  or  perform  the  actual 
construction  work.  The  Corps  is  an  engineering  organization  that  performs  Title  II 
services  which  include  supervision,  administration,  and  minimal  inspection  of  work 
performed  by  a  contractor.  While  the  owner  is  often  the  Corps,  with  the  Corps 
operating  and  maintaining  the  facility,  it  is  becoming  more  and  more  common  to 
have  a  local  sponsor  or  another  agency  owner.  The  Corps’  objective  is  to  design 
a  quality  and  innovative  product,  on  schedule,  and  within  budget  that  results  in  a 
totally  satisfied  customer. 


General  Requirements 

15.  In  order  to  define  the  LCPM  automated  information  criteria,  the  task 
group  had  to  address  three  requirements.  In  order  of  priority  these  are  the 
scheduling  and  reporting  requirements  mandated  with  the  implementation  of  LCPM 
(see  Table  V.l),  the  scheduling  and  reporting  requirements  currently  in  existence 
mandated  by  the  Corps  (see  Table  V.2),  and,  finally,  the  scheduling  and  reporting 
needs  of  management  internal  in  an  FOA  that  are  essential  to  the  execution  of  the 
work  (see  Table  V.3).  The  first  two  areas  clearly  require  a  database  management 
capability  to  generate  the  desired  information  and  to  create  the  reports  that  the 
executive  level  of  the  district  must  submit  as  upward  reporting  to  higher  authority. 
The  third  area,  dealing  with  the  production  level  of  the  organization,  must  focus  on 
detailed  project  scheduling  for  meeting  the  internal  needs  of  management  to  execute 
the  work  even  though  complementary  reporting  systems  are  also  needed.  The 
decentralized  nature  of  the  FOAs  and  their  individual  local  capabilities  encourage 
allowing  the  project  execution  requirements  internal  to  the  FOA  to  be  achieved 
using  a  detailed  scheduling  tool  that  is  either  provided  in  a  "preferred"  system  or 
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acquired  locally.  In  reality,  both  the  executive  and  production  levels  need  a  project 
management  system  that  has  project  scheduling  and  project  reporting  components. 

16.  The  philosophical  underpinning  for  the  approach  is  that  there  are  some 
universal  reports  (information)  that  every  FOA  must  provide.  The  format  for 
providing  these  reports  is  specified,  and  these  reports  are  mandatory.  The  detailed 
project  management  needs  internal  to  the  FOA  may  be  considered  somewhat 
universal  but  neither  the  content  of  the  gathered  information  nor  the  format  for 
presenting  the  material  is  mandated.  In  other  words,  the  FOA  has  considerable 
flexibility  in  satisfying  the  detailed  needs.  To  some  it  is  desirable  that  the  total 
needs  be  satisfied  with  the  same  system  and  that  the  Corps  LCPM  needs  at  both 
the  executive  and  production  levels  be  met  with  a  commercial  software.  Even  if 
such  a  package  can  be  obtained,  it  is  likely  that  some  FOAs  will  prefer  using  their 
own  system  to  meet  all  or  a  portion  of  the  detailed  project  management  needs.  The 
task  group  feels  that  as  long  as  the  detailed  system  will  provide  the  information 
needed  in  the  format  required,  the  FOA  should  be  free  to  use  the  system  of  their 
choice. 


District  Internal  Project  Management  Criteria 

17.  An  FOAs  daily  information  needs  are  many,  and  the  users  are  diverse. 
First-line  supervisors  need  detailed  information  on  the  status  of  their  projects  in 
terms  of  both  Finances  and  timeliness.  They  must  have  the  ability  to  plan  and 
schedule  down  to  the  individual  with  detailed  tasks  and  sub-tasks,  all  of  which  must 
be  tracked,  plus  obtain  the  feedback  necessary  to  evaluate  how  the  work  is 
progressing.  Branch  Chiefs  and  Division  Chiefs  have  increasingly  broader  levels  of 
information  needs  while  the  LCPM  must  view  their  projects  from  a  district 
perspective.  The  general  requirements  that  the  Project  Management  System 
software  should  satisfy  are  listed  below,  and  the  detailed  criteria  are  provided  in 
Table  V.3.  The  levels  of  importance  begin  at  1  to  indicate  the  feature  is  critical  to 
the  success  of  LCPM  implementation  and  general  FOA  project  management.  The 
levels  decrease  to  4  which  indicates  the  feature  is  important  enough  to  mention  but 
would  not  impact  the  success  or  LCPM  or  general  project  management. 
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18.  A  Project  Management  System  software  that  will  meet  the  requirements 
of  the  Corps  of  Engineers  should  consist  of  two  components:  a  project  scheduling 
component  and  a  project  control  component. 

19.  The  project  scheduling  component  should  have  the  following  general 
capabilities: 

-  An  activity-oriented  logic  network  feature  to  determine  critical  dates, 

-  the  ability  to  schedule  resources  and  compute  associated  costs, 

-  the  ability  to  project  cost  trends  over  time,  and 

-  the  ability  to  report  this  information  as  required. 

20.  The  project  control  component  should  have  the  following  general 
capabilities: 

-  The  ability  to  monitor  actual  information  relative  to  scheduled  estimates, 

-  an  audit  trail  feature  for  tracking  changes  to  the  approved  schedules, 

-  a  suspense  monitoring  system  for  managing  critical  actions, 

-  a  feature  for  scheduling  the  work  of  individuals  assigned  to  the  project, 

-  the  ability  to  report  this  information  as  required. 

21.  Most  commercially  available  "Project  Management"  software  packages  are 
in  reality  project  scheduling  packages,  while  project  control  systems  are  generally 
locally  produced  systems  built  upon  a  relational  database.  The  system  which  satisfies 
the  LCPM  needs  would  have  both  capabilities. 

22.  In  addition  to  the  above  functional  criteria,  the  system  should  also  have 
the  following  technical  features: 

-  interacts  with  the  user  in  a  friendly  manner, 

-  performs  internal  functions  without  user  downtime, 

-  ensures  retention  of  error-free  data, 

-  prevents  unauthorized  access, 

-  functions  on  an  open  DBMS  architecture, 

-  functions  identically  on  multiple  operating  systems, 

-  determines  early  and  late  start  dates  using  ASAP  or  ALAP  logic, 
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-  links  resources  to  a  project  from  a  central  pool, 

-  performs  ad  hoc  reporting  from  the  database, 

-  tolerates  individual  project  management  innovation  to  the  maximum 
extent  possible, 

-  has  the  ability  to  incorporate  a  Corps  standard  work  break  down 
structure  (WBS)  and  organizational  break  down  structure  (OBS), 

-  has  the  ability  to  incorporate  a  Corps  standard  milestone  code  structure 
that  would  indicate  dates  required  on  standard  reports, 

-  has  the  ability  to  incorporate  a  Corps  standard  method  of  system  use  so 
labor  hours  can  be  captured  successfully. 

23.  The  task  group  also  listed  some  assumptions  for  the  hardware  and 
software  environment  in  the  field  offices  during  the  short-  and  long-term  time 
frames.  The  short-term  assumptions  include: 

a.  All  existing  Corps  stovepipe  systems  will  remain  in  place  and  can  be 
used  to  input  data  into  the  preferred  software  package. 

b.  The  FOAs  have  existing  microcomputers  and  can  obtain  additional 
machines  with  relative  ease.  The  FOAs  do  not  have  existing  minicomputers  or 
mainframes  with  excess  capacity  and  cannot  immediately  obtain  them  even  if  the 
project  management  software  could  be  made  available  to  run  on  these  platforms. 

c.  A  Corporate  Database  System  will  not  be  available  initially  to  satisfy 
the  LCPM  and  other  mandatory  information  needs. 

d.  The  frequency  of  actual  data  input  will  be  determined  by  the  FOA 
consistent  with  the  data  being  gathered  in  the  stovepipe  systems. 

e.  A  network  scheduling  capability  is  needed  at  all  operating  levels.  Each 
FOA  may  determine  to  what  level  of  the  organization  below  IPM/TPM  they  wish 
to  implement. 
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f.  Network  activity  data  are  provided  to  the  project  managers  by  the 
functional  elements,  and  actual  data  come  from  both  the  standard  and  stovepipe 
systems. 

g.  The  LCPM  software  will  interface  with  Corps  stovepipe  systems  and 
with  other  systems  as  required. 

24.  In  addition  to  the  above  assumptions,  the  following  were  assumed  to 
happen  in  about  2  to  3  years: 

a.  The  redesigned  F&A  system  will  be  complete.  However,  some  stove¬ 
pipe  systems  will  exist  such  as  SAACONS,  ACPERS,  and  REMIS. 

b.  The  FOAs  will  have  minicomputers  or  mainframes  through  the  CEAP 
program  allowing  the  development  of  corporate  databases,  if  necessary,  and  the 
porting  of  their  PC-based  project  management  system  to  the  minicomputer  or 
mainframe. 

25.  The  task  group  developed  a  philosophy  on  LCPM  implementation  at  the 
district  level  to  aid  in  the  definition  of  requirements  and  evaluate  the  software 
systems.  This  is  provided  in  Appendix  C. 
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Table  V.l 


LCPM  REPORTING  REQUIREMENTS 

MANDATORY  REQUIREMENTS  -  The  reports  specified  by  Initiative  88  are  required  in 
both  form  and  content.  These  requirements,  found  in  EC  1110-2-536,  are  shown  below 
along  with  the  agency  responsible  for  preparing  the  report,  the  agencies  that  use  the 
report,  and  the  data  source  for  the  information. 


PROJECT  REPORTS  REQUIRED 

BY  EC  1110-2-536 

Title  of  Report 

ENG  Form 

Data  Source 

Weekly  Project  Manpower  Rpt 

4981-R 

‘District 

COEMIS 

Manual 

Project  Sch  &  Cost  Change  Rpt 

4975-R 

‘District 

Manual 

Monthly  Cost  Control  Change 

Rpt 

4976-R 

‘District 

Division 

EF4975-R 

COEMIS 

PRISM 

AMPRS 

Project  Monitoring  Rpt 

4980- R 

‘District 

Division 

HQUSACE 

PRISM 

AMPRS 

OIC 

Monthly  Management  Rpt 

4979-R 

‘District 

Division 

HQUSACE 

OASA 

COEMIS 

PRISM 

AMPRS 

Network 

Continuous  Project  "S"  Curve  Rpt 

4973-R 

‘District 

Division 

HQUSACE 

OASA 

COEMIS 

PRISM 

AMPRS 

Network 

Project  Review  Board  Minutes 

‘District 

Division 

Narrative 

Division  Executive  Summary 

‘Division 

HQUSACE 

Narrative 

HQUSACE  Highlight  Rpt 

‘HQUSACE 

Narrative 

*  Organization  responsible  for  preparing  report. 
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Table  V.2 


OTHER  MANDATORY  PROJECT  MANAGEMENT  REPORTING 
REQUIREMENTS 

The  reports  specified  by  higher  authority  other  than  those  in  Initiative  88  are  required 
in  both  form  and  content.  These  requirements  are  shown  below  along  with  the  agency 
responsible  for  preparing  the  report,  the  agencies  that  use  the  report,  and  the  data 
source  for  the  information. 


Title  of  Report _ ENG  Form  Report  Vsaee  Data  Source 


Detailed  Project  Sch  of  Funds 

PB-2A 

*LCPM 

PMO,Div, 

HQUSACE 

Dist  Sch 

CD,ED,OD, 

RE 

Project  Cost  Estimate 

PB-3 

*LCPM 

PMO,Div 

Design  Memo 

Study  Cost  Estimate 

PB-6 

*PD 

Div 

PD, ED, RE 

Cost  Rpt  by  Appropriation  & 
Division 

FB-4 

*PMO 

District 

COEMIS 

F&A 

Summary  Cost  Rpt  by  Division 

FB-5 

*PMO 

District 

COEMIS 

F&A 

Status  Obligations  & 

Expenditures 

2101 

*PMO 

District 

3011 A 

Appropriations  &  Work 
Allowances 

3011 A 

*DC 

Disl.Div, 

HQUSACE 

COEMIS 

F&A 

FY  Cost-Budget  Summary 

3018B 

*DC 

Div,  HQUSACE 

COEMIS 

F&A 

Data  for  Testifying  Officers 

DTO 

*LCPM 

PMO,Div 

PB-3.PB-2A 

DTO  Justification  Sheet 

DTO 

*LCPM 

PMO,Div, 

HQUSACE, 

Congr 

PB-2A 

*  Organization  responsible  for  preparing  report. 
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Table  V.3 


DETAILED  CAPABILITIES/CRITERIA 


A.  Networking  Capabilities 
_ Capability _ 

Interactive  Access  to  Data 
Importance:  1 

Loop  Detection 
Importance:  1 

Multiple  Calendars 
Importance:  1 
7-Day  Weeks. 

Multiple  Start  and  Finish  Activities 
Importance:  1 

Network  Methodology 
Importance:  1 

Schedule  Analysis 
Importance:  1 


What  if  Analysis 
Importance:  1 

Work  Break  Down  Structures 
(Forms  4979  and  4981) 
Importance:  1 

Logic  Drawing 
Importance:  2 


Minimum  Working  Unit  Time 
Importance:  3 


_ Description _ 

Ability  to  Interactively  Review  and  Edit 
Selective  Activity  Data  in  a  Tabular 
Format. 

Loop  Detection  of  Logic  Network. 


Activities  and  Resources  Scheduled  Based 
on  a  Combination  of  5-,  6-,  or 


Ability  to  Accommodate  Multiple  Start 
and  Finish  Activities. 

Arrow  (ADM)  and/or  Precedence  (PDM) 
Notation  Acceptable.  A  System  with  Both 
Capabilities  is  Preferred. 

Ability  to  Establish  Target  Start/Finish 
Dates  and  Compute  Intermediate  Activity 
Dates  Based  on  Dependencies.  (Backward 
Scheduling,  Resource  Limited  Scheduling, 
Time  Limited  Scheduling). 

Support  What  if  Analysis  for  All 
Resources. 

Ability  to  Define  a  Hierarchy  of  Work 
Items  Within  the  Project. 


Ability  to  Create  and  Modify  the  Logic 
Drawing  on  the  Screen  (Interactive 
Network  Editor). 

System  Allows  the  Minimum  Activity 
Time  Unit  Scheduled  as  1  Day  and 
Minimum  Resource  Time  Unit  as 
1  Hour. 


I 
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Table  V.3  (Continued) 


B.  Reporting  Capabilities 

_ Capability _ 

Ad-hoc  Query  &  Computation 
Importance:  1 


Automatic  Spreading  of  Resources 
Over  Time 
(Form  2101) 

Importance:  1 

Cost  Trend  Analysis 
Importance:  1 


Earned  Value  Reporting 
Importance:  1 


Gantt  Charts 
Importance:  1 

Graphical  Text  Reporting 
Importance:  1 


Logic  Drawing 
Importance:  1 

On  Screen  Reports 
Importance:  1 

Physical  Percent  Complete  Reporting 
Importance:  1 

Query  System 
Importance:  1 


Report  Flexibility 
Importance:  1 


_ Description _ 

Ability  for  the  User  to  Query  the  Data 
Contained  in  the  System  and  Use  it  to 
Perform  Basic  Computations  (e.g., 

Percent  E&D  Based  on  Construction 
Costs)  and  Produce  Reports.  Ability  to 
Perform  Exception  Reporting  and 
Suspense  Reporting. 

The  Ability  to  Spread  Resourccs/Costs 
Over  User  Defined  Time  Periods  to 
Accomplish  Obligations  and  Expenditures. 


Ability  to  Develop  Cost  Trend  Analysis 
by  Features  and  Project  Types  to  Produce 
"S"  Curve  Type  Data. 

Ability  to  Compare  Scheduled  Progress  to 
Actual  Progress  and  Report  Earned 
Value. 

Ability  to  Produce  Gantt  Chart  (Bar 
Charts)  from  the  Activity  Information. 

Ability  to  Automatically  Note  Critical 
Dates  and  Customized  Text  on  the 
Network  Logic  or  Gantt  Chart. 

Ability  to  Generate  a  Network  Logic 
Drawing  from  Activity  Information. 

Ability  to  View  and  Edit  Reports  on  the 
Screen. 

System  to  Provide  for  Manual  Input 
Physical  Progress  of  Activities. 

Ability  to  Support  Ad  hoc  and  Structured 
Queries  of  Activity  and  Resource 
Information. 

Ability  to  Generate  User-Defined  Reports 
Within  the  Software. 


Reporting  Time  Frames 
(Forms  2101  and  PB-2A) 
Importance:  1 


Ability  to  Establish  Reporting  Time 
Frames  by  FY,  Qtr,  Month,  Day. 


Table  V.3  (Continued) 


Capability  ( Continued} _  _ Description  ( Continued ) 


Roll-Up  Capabilities 

Importance:  1 

Ability  to  Roll-Up  Resources  by 
Organization  and/or  Activities  to 
Managerial  Interest  Levels  (e.g.,  by 
Division  or  by  Appropriation,  etc.). 

Tracking  Progress 
(Form  4976) 

Importance:  1 

Ability  to  Compare  Baseline,  Revised, 
and  the  Scheduled  vs.  Actual  Progress 
of  Activities. 

Change  Tracking 
(Form  4975) 

Importance:  2 

Ability  to  Automate  the  Sequential 

Change  Request  Numbering. 

Computational  Capabilities 
(Forms  4980  and  4979) 

Importance:  2 

Ability  to  Perform  Group  Costs  as 
Specified  by  the  User  (Resource  or  Work 
Break  Down  Structures,  etc.)  and  Perform 
Mathematical  Operations  on  the  Totals. 

Histogram  Reporting 

Importance:  2 

Ability  to  Obtain  Histogram  Reporting 
from  Network  Data. 

Graphic  Displays 

Importance:  3 

Ability  to  Produce  Pie,  Line,  and  Bar 
Charts. 
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Table  V.3  (Continued) 


C.  Resource  Capabilities 
_ Capability 

Manner  Codes 
(Form  4979) 

Importance:  1 

Organizational  Break  Down 
Importance:  1 


Resource  Distribution 
Importance:  1 

Resource  Leveling 
Importance:  1 

Fixed/Variable  Resources 
Importance:  3 

Individual  Scheduling 
Importance:  3 


_  _ Description _ 

Ability  to  Identify  Resources  by  Specific 
Categories  (Work  Done  by  Others, 
In-House  Hired  Labor,  etc.). 

Structure  Ability  to  Establish  Resources  by 

Organizational  Element,  by  Position 
Classification,  and  by  Individual  and 
Apply  Them  in  the  Form  of  Manpower, 
Dollars,  and  Time. 

Ability  to  Prorate  Resource  Usage  Over 
Time. 

Ability  to  Optimize  Resource  Utilization 
Across  All  Projects. 

Ability  to  Establish  Variable  Resource 
Levels. 

Ability  to  Schedule  Individuals  Assigned 
to  Each  Activity  by  Name. 
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Table  V.3  (Continued) 


D.  Interface  Capabilities 
_ Capability _ 

Interface  with  Corps  Standard  Systems 
Importance:  1 


Project  Funds  Status 
Importance:  1 


Word  Processing 
Importance:  1 

Access  to  Non-network  Data 
Importance:  2 


Compatible  File  Formats 
Importance:  4 


_ Description _ 

System  to  Interface  with  Corps  Standard 
Systems.  The  COEMIS  F&A  System  is 
Required,  Others  such  as  AMPRS, 
PRISM,  SAACONS,  REMIS,  and 
CACES,  etc.,  are  Required  Within 
12  Months  after  Implementation. 

Ability  to  Obtain  Project  Funds  Status 
for  Monitoring  Obligations  and 
Expenditures. 

System  Must  be  Able  to  Link/ Access 
Word  Processing  Software. 

Ability  to  Access  Data  Contained  in 
Other  Databases  for  Use  in  Report 
Preparation  (e.g.,  Cost  Estimates  Based 
on  Code  of  Accounts). 

System  Must  be  Able  to  Import  from  and 
Export  to  dBase  and  ASCII  Files.  It 
Would  be  Desirable  if  the  System  Could 
Also  Interface  with  ORACLE. 
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Table  V.3  (Concluded) 


E.  Other  Capabilities 
_ Capability _ 

Ability  to  Define  Project  Attributes 
(Forms  4979  and  4981) 

Importance:  1 


Customization  of  the  Database 
Importance:  1 

Database  Oriented 
Importance:  1 

Documentation/Support 
Importance:  1 


LAN  Environment 
Importance:  1 

User  Interface 
Importance:  1 

Flexible  Data  Input 
Importance:  2 

Mini/Mainframe  Environment 
Importance:  2 

Modifications  &  Claims  Tracking 
Importance:  2 

Project  Changes  System 
(Form  4975) 

Importance:  2 

Provide  an  Audit  Trail 
Importance:  2 

Risk  Analysis 
Importance:  3 

Security 
Importance:  3 


_ Description _ 

Ability  to  Define  General  Project 
Descriptions  such  as  Name  of  Project, 
District,  Division,  etc.,  for  Use  in 
Heading  Information  on  Reports. 

Ability  to  Add  User-Defined  Data  Fields. 


The  System  Should  Run  Directly  Within 
a  Relational  Database  System. 

The  System  Must  Be  Well  Documented 
and  Supported  by  a  Technical  Staff 
Available  to  Answer  User  Questions. 

The  Ability  to  Operate  on  a  Local  Area 
Network. 

The  System  Should  Have  a  Logical,  Easy 
to  Understand  User  Interface. 

The  Ability  of  the  User  to  Create  Custom 
Input  Screens. 

The  Ability  for  the  System  to  Operate  in 
a  Mini/Mainframe  Environment. 

System  to  Provide  for  Tracking  Project 
Claims  and  Modification. 

Ability  to  Store  Changes  to  the  Project  in 
in  a  File  with  Network  Interface. 


System  to  Provide  an  Audit  Trail  of 
Changes  Made  to  the  Schedule  Activities 
and  Resources. 

System  to  Provide  Risk  Analysis. 


The  Ability  to  Specify  Who  has  the 
Authority  to  Control  Reading,  Writing, 
Changing,  and  Deleting  Project  Data. 
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VI.  Software  Survey 


26.  A  survey  of  commercially  available  software  for  project  management  was 
performed  to  determine  the  most  likely  vendors  who  could  satisfy  the  task  group 
criteria.  Appendix  D  contains  a  list  of  the  software  and  vendors  considered. 

27.  Six  vendors  were  selected  as  candidates  for  review  by  the  task  group.  A 
list  of  capabilities  to  be  demonstrated  was  sent  to  the  candidate  vendors  several 
working  days  prior  to  the  visit  by  the  task  group.  These  demonstration  criteria  are 
contained  in  Appendix  E.  All  vendors  attempted  to  show  that  their  software  could 
meet  the  criteria  while  deviating  to  dwell  on  the  individual  strengths  of  their 
software. 

28.  The  vendors  visited  by  the  task  group  and  their  products  were: 

Welcom  Software  Technology,  Houston,  TX  (OPEN  PLAN) 

Metier  Management  Systems,  Houston,  TX  (ARTEMIS) 

Symantec,  Nevado,  CA  (TIMELINE) 

Bechtel  Software,  Gaithersburg,  MD  (SYNERGY) 

AGS  Management  Systems,  King  of  Prussia,  PA  (WINGS) 

Primavera  Systems  Inc.,  Bala  Cynwyd,  PA  (PRIMAVERA  PROJECT 
PLANNER) 

29.  The  software  review  was  conducted  7-10  March  89  in  the  respective 
vendors’  facilities. 
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VII.  Findings 


30.  Software  is  currently  available  on  the  commercial  market  that  can  satisfy 
the  requirements  of  LCPM.  The  software  systems  reviewed  by  the  team  offered  a 
range  of  capabilities  from  a  basic  planning  and  scheduling  tool  to  a  comprehensive 
planning,  scheduling,  monitoring,  and  controlling  tool  with  a  large  integrated 
database.  One  vendor  even  offered  several  modules  including  a  cost  construction 
estimating  package.  Each  software  package  has  advantages  and  disadvantages  for 
working  in  the  Corps  environment;  however,  each  one  could  be  utilized  by  a  district 
with  differing  degrees  of  effort.  All  of  the  packages  would  allow  for  a  progression 
to  larger  and  broader  systems  in  the  future  with  minimal  loss  of  effort.  Individual 
product  reviews  are  included  in  Appendix  F. 

31.  Two  factors  did  stand  out  in  the  review.  One  was  the  flexibility  of  some 
products  allowing  the  user  to  alter  the  database,  the  input  screens,  and  the  reports 
obtained  from  the  database.  The  second  factor  was  the  diversity  of  databases  used 
by  the  systems.  One  software  package  used  dBase  III  +  which  would  tie  into 
databases  that  already  exist  in  many  districts.  The  other  database  used  was 
ORACLE.  Even  though  ORACLE  is  currently  being  used  in  only  a  very  few  loca¬ 
tions,  it  may  well  become  the  standard  in  the  future.  While  dBase  III+  and 
ORACLE  are  general  purpose  relational  database  management  systems,  several 
vendors  use  a  special  purpose  project  database  system. 

PRISM  and  AMPERS 

32.  The  task  group  also  looked  at  using  PRISM  and  AMPERS  as  LCPM 
tools.  Those  findings  are  summarized  in  the  following  paragraphs. 

Use  of  PRISM  for  LCPM 

33.  PRISM  development  focused  on  Civil  Works  construction  projects. 
Although  Planning,  Operations,  Maintenance,  and  Military  Construction  projects  can 
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use  PRISM,  these  generally  require  "work-around"  solutions.  PRISM  can  serve  as 
the  data  repository  with  some  enhancements.  PRISM  also  has  the  ability  to  store 
several  iterations  of  project  data  so  that  a  history  of  changes  could  be  viewed.  The 
PRISM  option  requires  additional  investigation,  but  using  PRISM  as  the  total 
LCPM  solution  at  the  IPM/TPM  level  does  not  appear  to  be  a  viable  option. 

Use  of  AMPRS  for  LCPM 

34.  AMPRS  does  not  have  any  project  scheduling  capabilities.  AMPRS  is  a 
repository  of  information  and  could  serve  as  the  repository  of  data  transmitted  from 
PCs.  To  handle  the  information,  AMPRS  will  need  to  be  expanded  to  store  data 
not  currently  accommodated.  AMPRS  as  the  total  LCPM  solution  at  the  IPM/TPM 
level  does  not  appear  to  be  a  viable  option. 

Information  Systems  Modernization  Plan  (ISMP)  Emphasis 

35.  The  Corps  published  ISMP  philosophy  calls  for  the  development  of  an  in¬ 
tegrated  database  with  applications  running  on  this  database.  The  Private  Sector 
Council  study  criticized  this  approach.  The  task  group  examined  both  an  integrated 
(see  Fig.  VII.  1)  and  an  interfaced  system  approach  (see  Fig.  VII.2)  for 
implementation. 

Integrated  system  approach 

36.  The  advantages  of  an  integrated  database  are  well  documented:  all  users 
can  have  access  to  the  necessary  data,  all  data  is  in  a  pool  of  information,  a  single 
tool  is  used  to  retrieve  all  information,  the  data  mean  the  same  thing  to  everyone, 
singular  data  storage  and  singular  data  entry  are  provided,  etc.  These  are  attrac¬ 
tive  arguments  to  the  concept  of  integration  of  data. 

37.  The  integrated  system  approach  would  require  all  data  to  reside  on  a 
singular  platform  and  all  applications  to  use  a  simple  Relational  Database 
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NOTE:  ALL  APPLICATIONS  RUN  ON  THE  SAME  RELATIONAL  DATABASE  MANAGEMENT 
SYSTEM.  TOTAL  INTEGRATION  MANDATES  MINIMAL  DATA  REDUNDANCY. 
PARTIAL  INTEGRATION  INDICATES  DATA  SHARING  USING  BACKGROUND  UTILITIES 
AND  INCREASED  DATA  REDUNDANCY. 


FIGURE  VII.  1.  INTEGRATED  APPROACH 


NOTE:  APPLICATIONS  DO  NOT  RUN  ON  THE  DATABASE. 
THEY  ONLY  UPLOAD/DOWNLOAD  INFORMATION. 


FIGURE  VII. 2.  INTERFACED  APPROACH 


Management  System  (RDBMS).  Total  or  partial  integration  as  shown  in  Fig.  VII.  1 
is  possible.  Of  the  products  reviewed,  SYNERGY  (by  Bechtel  Software)  embraces 
the  concept  of  partial  integration.  No  product  surveyed  had  total  integration. 

38.  The  task  group  performed  rough  calculations  to  estimate  the  size  of  a 
detailed  project  database  for  a  typical  district.  The  expected  size  of  a  database  for 
a  typical  single  project  over  the  life  cycle  would  be  about  1  megabyte.  However, 
when  all  projects  in  all  districts  of  a  division  are  integrated,  the  expected  size  of  a 
division  integrated  database  could  approach  500  megabytes.  Limitations  of  an 
integrated  database  become  compounded  during  a  frantic  "what  if’  scenario  (e.g., 
what  is  the  project  impact  if  the  budget  is  cut  10%?)  when  at  least  50%  of  all 
projects  would  be  involved.  The  database  would  contain  duplicate  or  even  triplicate 
versions  of  project  details  to  answer  and  justify  the  requested  information.  This 
could  expand  an  integrated  division  database  to  1  gigabyte  or  more. 

39.  The  cost  of  integration  is  not  just  in  the  software  used  to  employ  the 
technology,  but  also  in  the  support  personnel  required  to  maintain  the  database. 
Some  of  the  problems  associated  with  the  integrated  approach  are  discussed  below. 

a.  Integrating  data  will  require  hardware  and  software  procurement  to 
immediately  handle  the  additional  work  load.  Since  a  hardware  procurement  impacts 
CEAP  and  CEAP  is  a  phased  implementation,  a  time-sharing  facility  would  be  the 
only  alternative.  However,  using  a  time-sharing  facility  in  an  interactive  mode  for 
this  purpose  would  be  so  inefficient  that  it  would  be  impractical.  Also,  an  RDBMS 
must  be  procured  for  the  installed  hardware.  An  RDBMS  requires  more  hardware 
for  overhead  functions,  and  the  on-line  nature  of  RDBMS  data  encourages  more 
sophisticated  queries.  While  the  database  for  LCPM  does  not  appear  to  be  very 
large,  neither  is  it  trivial. 

b.  Support  personnel  must  be  readily  available  for  user  assistance  and 
system  maintenance.  It  is  expensive  to  train  personnel  in  database  administration 
(DBA)  skills  with  LCPM.  Being  a  critical  system,  the  best  people  the  Corps  has 
must  be  put  in  charge  of  the  LCPM  database.  The  Corps  docs  not  have  extensive 
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knowledge  of  DBA  with  a  relational  database  in  all  field  offices.  The  skill  level 
necessary  usually  requires  training  and  a  least  2  years  of  experience.  The  risk  of 
database  failure  is  quite  high  with  inexperienced  personnel. 

c.  Database  integrity  must  be  continually  monitored.  Referential  integrity 
(ensuring  all  data  are  referentially  pure)  is  the  difference  between  accurate 
information,  lack  of  information,  and  misinformation  in  database  queries.  Currently 
there  is  no  system  that  automates  referential  integrity;  therefore,  all  application 
development  must  check  the  integrity  of  related  data.  In  an  integrated  system,  these 
references  would  be  in  several  of  the  tables  throughout  the  database.  The  lack  of 
referential  integrity  would  cause  success  of  an  application  to  be  unlikely. 

d.  Performance  must  be  continually  monitored.  An  RDBMS  n;ay  require 
from  three  to  several  hundred  times  the  processing  power  of  either  a  network  or 
an  hierarchical  DBMS.  The  broad  range  is  based  on  how  the  RDBMS  is  structured 
as  opposed  to  how  the  comparison  system  is  structured.  Performance  problems 
can  be  corrected  by  (a)  a  well-coded  system,  (b)  index  usage,  and  (c)  data  table 
definitions  and  other  factors.  However,  knowledgeable  personnel  with  experience 
are  needed  to  tune  a  system  if  performance  begins  to  degrade. 

Interfaced  systems  approach 

40.  The  Corps  has  been  operating  with  interfaced  systems  since  the  early  days 
of  automation.  The  disadvantages  are  well  publicized.  The  advantages  are  not  so 
well  publicized  in  recent  documents.  In  general,  the  advantages  are  solutions  to  the 
disadvantages  of  integration.  In  the  interface  approach,  the  district  project  managers 
will  have  all  the  necessary  tools  for  daily  operation  on  a  PC,  and  the  district  could 
have  an  integrated  database  containing  project  details  for  total  district  management 
reporting.  The  district  level  integrated  database  would  be  updated  by  the  IPM/TPM 
periodically.  The  division  would  have  an  integrated  database  of  summary 
information  for  division  level  management  reporting.  This  division  summary  data 
would  be  updated  by  the  district  project  managers  periodically.  Finally,  HQUSACE 
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would  have  an  integrated  database  of  ail  necessary  LCPM  data  that  would  be 
updated  from  the  divisions  periodically. 

Preferred  approach 

41.  The  task  group  considers  an  interfaced  database  approach  as  shown  in  Fig. 
VII.2  as  the  best  way  to  implement  LCPM  in  the  Corps.  Software  tools  are 
commercially  available  to  facilitate  this  approach  such  that  any  district  could 
commence  implementing  LCPM.  The  commercial  software  would  also  allow  the 
districts  to  move  in  an  orderly  progression  to  larger  and  broader  systems  and 
eventually  to  a  district  corporate  database.  Detailed  reviews  of  the  software 
inspected  are  contained  in  Appendix  F,  and  recommendations  are  made  in 
Section  VIII  under  Implementation  Recommendations. 
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VIII.  Conclusions  and  Recommendations 

Conclusions 

42.  The  task  group  concluded  that: 

a.  Software  products  exist  in  the  commercial  market  that  could  be  used 
to  satisfy  LCPM  at  all  levels  of  management. 

b.  LCPM  requirements  at  the  district,  division,  and  HQUSACE  levels 
can  be  satisfied  by  providing  report  extracts  from  the  IPM/TPM  micro  systems. 

c.  A  micro-based  project  management  system  consisting  of  a  project 
scheduler  and  a  DBMS  must  be  identified  as  part  of  a  recommended  system  to  be 
used  by  the  IPM/TPM.  This  would  save  money  in  developing  interfaces  with 
stovepipe  systems  such  as  COEMIS  F&A,  PRISM,  and  AMPRS.  However,  the 
FOAs  should  be  allowed  to  use  any  project  scheduling  system  below  the  IPM/TPM 
level. 

Recommendations 

43.  The  task  group’s  recommendations  are  divided  into  two  parts:  general 
recommendations  that  apply  regardless  of  the  implementation  strategy  taken  by 
USACE,  and  recommendations  on  how  to  implement  LCPM  using  commercially 
available  software. 

General  recommendations 

44.  General  recommendations  include: 

a.  Select  a  "preferred"  project  networking  system  that  would  complement 
the  data  collection  requirement  for  use  by  the  IPMATPM.  A  preferred  system  is  a 
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system  that  is  well  supported  but  is  not  necessarily  a  standard.  Experience  with 
engineering  software  indicates  that  successful  standards  evolve  rather  than  being 
imposed.  A  well-supported  preferred  system  is  likely  to  become  a  defacto  standard 
eventually.  This  recommendation  is  made  due  to  the  economies  of  scale  associates 
with  common  software  development.  In  addition,  the  common  system  would 
promote  the  movement  toward  electronic  project  reporting. 

b.  Standardize  the  LCPM  reporting  database  structures  from  USACE  to 
the  district  level.  This  should  be  done  with  field  input  through  a  task  group. 

c.  Develop  a  standard  work  break  down  structure  (WBS)  and  an 
organization  break  down  structure  (OBS).  These  standards  are  essential  within  a 
district  in  order  to  roll  up  projects  and  evaluate  resources.  They  are  also  essential 
for  a  division  if  they  plan  to  roll  up  projects  from  several  districts,  and  for 
HQUSACE  if  they  desire  to  roll  up  all  work  within  the  Corps.  This  effort  should 
be  done  with  field  input  through  a  task  group. 

d.  LCPM  and  project  management  systems  need  accurate  and  timely 
finance  and  accounting  information  to  be  useful.  The  current  COEMIS  F&A 
system  does  not  meet  this  requirement.  It  is  recommended  that  a  new  F&A  system 
that  meets  the  needs  of  not  only  the  Comptroller  but  also  the  resource  and  project 
managers  be  procured  or  developed  as  soon  as  possible.  As  part  of  the  COEMIS 
F&A  redesign  effort,  a  study  similar  to  the  one  undertaken  here  should  be 
performed  (if  not  already  done)  to  ascertain  whether  commercial  F&A  systems  are 
available  to  meet  the  Corps’  needs.  This  could  hasten  the  process. 

e.  Establish  a  Center  for  Computer-Aided  Project  Management  (CCAPM) 
in  the  Corps  similar  to  the  Computer-Aided  Design  and  Drafting  (CADD)  Center 
at  the  Waterways  Experiment  Station.  The  Center,  like  the  CADD  Center,  should 
be  field-driven  and  should  become  the  focal  point  for  fostering  project  management 
activities  in  the  Corps.  The  Center  would  be  the  working  arm  for  the  HQ  Program 
Manager  for  LCPM.  The  Center  should  be  small,  staffed  by  experienced  engineers 
and  computer  scientists.  The  CCAPM  would  strengthen  the  concept  of  HQ 
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providing  direction  and  leaving  the  execution  to  the  field.  The  CCAPM  would  work 
under  the  direction  of  a  Field  Advisory  Group  (similar  to  the  CADD  Center).  This 
advisory  group,  consisting  of  field  office  and  HQ  personnel,  would  be  selected  by 
the  HQ  Program  Manager  for  LCPM.  Functions  of  the  CCAPM  would  include: 

(1)  Select  a  "preferred"  project  management  system(s)  based  on  the 
implementation  recommendations  described  below  and  assist  with  procurement. 

(2)  Form  field  task  groups  to  standardize  data  structures  at  all  levels 
and  to  develop  standard  WBS  and  OBS. 

(3)  Become  a  catalyst  for  field  offices  to  exchange  requirements  and 
expertise  on  project  management. 

(4)  Facilitate  training  of  engineers  and  managers  in  project  manage¬ 
ment.  The  task  group  feels  that  there  is  an  urgent  need  to  train  engineers  in  the 
field  offices  on  the  concepts  of  LCPM  and  in  the  use  of  project  management 
software  tools. 

(5)  Provide  guidance  for  exchanging  data  between  the  stovepipe 
systems  and  the  project  management  database  to  minimize  the  problems  the  FOAs 
might  encounter. 

(6)  Identify  the  required  interfaces  for  customizing  the  recommended 
project  management  system  software. 

(7)  Distribute  centrally  developed  interface  programs  as  well  as  other 
programs  developed  by  various  districts  to  facilitate  managing  and  executing  LCPM 
tasks. 


(8)  Use  district  resources  as  much  as  possible  to  accomplish  tasks. 
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f.  Further  investigate  the  role  of  PRISM/AMPRS  in  the  environment 
where  project  scheduling  will  be  done  using  a  commercial  software  system. 

g.  During  CEAP  pilot  testing  consider  the  impact  of  CEAP  and  the 
redesigned  F&A  system  on  the  recommendations.  Examples  of  impacts  are: 
possible  changes  from  one  RDBMS  to  another,  migration  from  PC  file  servers  to 
minicomputers/mainframes,  integration  of  data  in  corporate  databases  (if  available), 
etc.  Changes  to  a  recommended  micro-based  project  management  system  to  allow 
porting  of  the  system  to  a  minicomputer  or  mainframe  should  also  be  identified 
during  the  CEAP  pilot  test  period. 

Implementation  recommendations 

45.  The  task  group  recommends  an  implementation  strategy  using  commer¬ 
cially  available  software  and  an  interfaced  approach.  Under  this  strategy  data  at  all 
levels  of  management  will  be  kept  at  a  manageable  level.  The  critical  success  factor 
is  that  all  levels,  HQUSACE  down  to  district  management,  must  accommodate  the 
next  higher  level  in  data  transmitted,  and  the  higher  level  must  decide  what  data  are 
needed  for  its  level  of  management.  The  definition  of  data  required  for  manage¬ 
ment  at  HQUSACE  must  be  defined  first  so  that  subordinate  offices  can  define 
their  data  requirements.  Specific  types  of  software  for  each  level  and  aspect  of 
project  management  is  discussed  below. 

a.  Project  Planning  &  Scheduling.  The  task  group  recommends  im¬ 
plementing  planning  and  scheduling  functions  for  the  IPM/TPM  and  resource 
manager  on  a  PC.  The  tools  available  on  the  market  allow  for  quick  and  accurate 
development  of  plans  and  schedules.  The  specific  tool  viewed  by  the  task  group 
that  best  suited  this  purpose  was  Timeline  by  Symantec.  Other  tools  exist  and  all 
tools  viewed  by  the  task  group  could  perform  planning  and  scheduling.  The 
Timeline  class  of  products  would  be  limited  to  a  planning  and  scheduling  role.  The 
task  group  is  not  recommending  Timeline  as  the  only  solution,  but  only  as  the  class 
of  software  that  provides  a  solution. 
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b.  Project  Monitoring  &  Control.  The  task  group  recommends 
implementing  monitoring  and  control  functions  in  a  rigorous  PC  software  package 
like  Open  Plan  by  Welcom  Software  or  Project  Planner  by  Primavera.  These 
packages  offer  in-depth  analysis  and  graphical  capabilities.  Open  Plan  is  more 
flexible  since  it  is  based  on  dBase  III+,  whereas  Project  Planner’s  graphical 
reporting  is  by  far  the  best  and  is  well  suited  for  presentation  development.  Open 
Plan  provides  greatest  flexibility  for  user  modification  of  data  entry  and  textual 
reporting.  Project  Planner  provides  greatest  flexibility  for  graphical  reporting. 
These  packages  or  one  like  them  appears  to  provide  the  IPM/TPM  the  majority  of 
tools  necessary  to  perform  data-related  work.  Additional  tools  would  be  necessary 
to  handle  Congressional,  Corps-specific,  and  manager-specific  efforts  and  to 
summarize  data  for  transmittal  to  the  summary  databases.  This  solution  allows  the 
IPM/TPM  to  determine  the  software  most  useful  for  them  and  have  a  data  transfer 
utility  written  to  move  data  from  the  PC  software  to  the  summary  district  database. 
Again,  the  task  group  is  not  recommending  a  specific  software  but  rather  the  class 
of  software. 

c.  Project  Summarization.  The  task  group  recommends  implementing 
the  provision  of  summary  information  for  district  use  in  a  standard  relational 
database  management  system  (e.g.,  dBase  III+,  dBase  IV,  FoxBase  2.1,  Oracle). 
The  major  purpose  of  this  repository  is  to  collect  all  project  summary  data  from  the 
IPM/TPM  and  hold  it  for  management  reporting.  It  would  be  the  purpose  of  the 
enterprise  (e.g.,  district)  managing  the  repository  to  determine  the  data  elements 
required  for  storage  and  the  detail  necessary.  Due  to  the  concept  of  LCPM, 
HQUSACE  should  develop  the  data  requirements  needed  for  management  prior 
to  the  division  offices  developing  their  own  requirements.  Similarly,  the  division 
offices  should  develop  their  requirements  prior  to  the  district  developing  their 
requirements.  The  data  would  be  electronically  transmitted  from  the  districts  up  to 
HQUSACE  through  the  divisions. 

46.  Implementation  using  the  interface  approach  reduces  the  requirements  for 
a  large  mainframe  to  that  of  a  file  server  role.  It  allows  any  platform  from  a  high 
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capacity  microcomputer  to  a  minicomputer  or  mainframe  to  be  used.  The  respective 
offices  (district,  division,  HQUSACE)  could  procure  necessary  hardware  based  upon 
their  management  requirements  and  funds  available.  The  task  group  further 
recommends  the  interfaced  approach  to  LCPM  as  the  only  solution  that  can  be 
feasibly  implemented  immediately.  This  does  not  preclude  the  organization  from 
moving  to  an  integrated  approach  as  the  necessary  hardware  becomes  available, 
personnel  are  trained,  and  the  DBMS  software  on  the  market  matures  to  the  extent 
that  integration  becomes  a  low-risk  alternative. 

47.  On  the  contrary,  if  HQ  desires  an  integrated  approach  with  all  or  most 
applications  sharing  data  with  minimal  data  redundancy,  the  task  group  recommends 
SYNERGY  developed  by  Bechtel  Software  as  the  only  viable  solution.  However, 
this  software  must  be  tested  in  a  pilot  district  and  evaluated  before  further  steps  are 
taken. 
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APPENDIX  A  -  DEFINITIONS 


1.  Activity  -  An  identifiable  section  of  work  required  to  complete  a  project. 

2.  Actual  -  Historical  data  of  time,  resource,  and  money  consumed  in  work. 

3.  Arrow  Diagramming  Method  (ADM)  -  A  method  that  identifies  an  activity  using 
I  and  J  nodes.  Network  logic  is  defined  by  identifying  events  as  nodes  and  each 
activity  occurs  between  two  events. 

4.  Baseline  -  The  schedule  and  related  data  approved  by  authorities  responsible  for 
the  project. 

5.  Current  -  The  schedule  and  related  data  identified  as  the  most  recently  approved 
plan  for  project  execution. 

6.  Database  Management  Based  Reporting  System  -  A  component  of  the  Project 
Management  System  (PMS)  that  provides  both  a  database  for  the  collection  of  data 
from  the  PMS  and  the  Corps  stovepipe  systems,  and  manual  input  and  a  report 
generator  for  preparing  both  mandatory  and  desirable  project  reports. 

7.  DBA  -  Data  Base  Administrator. 

8.  Early  Start  Data  (ES)  -  The  earliest  date  an  activity  can  begin. 

9.  Early  Finish  Data  (EF)  -  The  earliest  date  an  activity  can  be  expected  to  be 
complete. 

10.  Free  Float  (FF)  -  The  amount  of  time  an  activity  can  slip  without  affecting 
successor  activities. 

11.  FOA  -  Field  Operating  Agency. 
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12.  IPM  -  Independent  Project  Manager. 


13.  LCPM  -  Life  Cycle  Project  Management.  The  management  approach  used  by 
the  Corps  of  Engineers  to  accomplish  its  project  on  schedule  and  within  budget 
through  the  use  of  Independent  Project  Managers  and  Team  Project  Managers. 

14.  Late  Start  Date  (LS)  -  The  latest  date  an  activity  should  begin. 

15.  Late  Finish  Date  (LF)  -  The  latest  date  an  activity  should  be  completed. 

16.  Network  -  A  combination  of  activities  and  the  relationships  between  the 
activities.  Allows  for  ADM  or  precedence  diagramming  method  (PDM). 

17.  Network  Analysis  -  The  computation  of  dates  (ES,  LS,  EF,  LF)  and  slack  (FF, 
TF)  for  each  activity  or  task  within  a  network. 

18.  PC  -  Personal  (micro)  Computer. 

19.  Precedence  Diagramming  Method  (PDM)  -  A  method  that  identifies  an  activity 
with  a  unique  code.  Network  logic  is  defined  by  identifying  the  preceding  activities 
or  succeeding  activities  to  an  individual  activity. 

20.  Project  Management  System  (PMS)  -  The  two-part  system  used  to  manage  and 
control  the  execution  of  projects  at  a  Corps  facility.  The  project  scheduling 
component  provides  for  detail  down  to  the  lowest  authorized  organizational  level. 
The  project  control  component  consists  of  a  database  management  system  with 
report  generator  for  the  preparation  of  control  reports. 

21.  RDBMS  -  Relational  Database  Management  System 

22.  Resource  -  An  entity  that  when  utilized  depletes  money  from  available  project 
funds. 
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23.  Schedule  -  The  analyzed  network  which  provides  the  management  dates  of 
activities. 

24.  Task  -  The  lowest  identified  level  of  work.  Several  tasks  can  be  performed 
within  an  activity. 

25.  Total  Float  (TF)  -  The  amount  of  time  an  activity  can  slip  without  affecting  the 
project  late  finish  date. 

26.  TPM  -  Team  Project  Manager. 
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APPENDIX  C  -  LCPM  PHILOSOPHY 


Cl.  There  are  several  aspects  of  the  Corps’  mission  that  are  different  from 
those  of  a  commercial  enterprise  construction  company.  As  such,  the  philosophy  of 
LCPM  in  the  Corps  must  first  be  established  before  automated  systems  are  selected 
for  practicing  LCPM.  Some  of  these  issues  are  outlined  in  this  section. 

Functional  Responsibilities 

C2.  District  management  personnel  are  grouped  as  resource  managers  and 
independent  project  managers  (IPM). 

Resource  managers 

C3.  The  resource  manager  has  the  responsibility  to  accomplish  the  work  as 
well  as  the  identification  and  documentation  of  any  deviations  in  the  scope  of  work, 
schedule,  budget,  and  project  cost.  This  responsibility  requires  access  to  the  network 
including  all  planned  and  actual  data  from  which  they  can  monitor  and  evaluate  the 
progress  of  their  own  work.  This  of  course  is  not  done  in  isolation  but  in 
cooperation  with  the  entire  team  and  the  project  manager. 

Independent  project  managers 

C4.  The  IPM/TPM  has  the  responsibility  for  planning,  scheduling,  monitoring, 
and  controlling  the  project  from  a  district  perspective  as  well  as  identifying  and 
documenting  any  deviations  in  the  scope  of  work,  schedule,  budget,  and  project  cost. 
The  documentation  of  any  change  to  the  baseline  schedule,  resources,  and  cost 
should  be  attached  to  the  activity  generating  the  change.  The  documentation  would 
also  be  placed  in  a  database  so  that  there  is  a  clear  audit  trail  of  all  changes  with 
accumulative  impacts. 
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Project  Management  Philosophy 


C5.  The  team  believes  that  district  LCPM  level  should  commence  with 
initiation  of  the  reconnaissance  report  instead  of  waiting  until  the  feasibility  report 
is  completed.  This  creates  a  "cradle  to  grave"  management  of  the  project  (see 
Fig.  C.l).  The  cost  estimating,  project  planning,  and  project  scheduling  phases  coula 
be  handled  by  commercially  available  software.  It  is  assumed  that  the  IPM/TPM 
would  use  this  software.  The  project  monitoring  and  project  control  phases  are 
comparatively  long  duration  phases  which  would  require  more  rigorous  software  for 
the  daily  chores.  These  too  appear  to  be  available  commercially. 

C6.  A  Corps  IPM/TPM  is  responsible  for  control  of  an  assigned  project.  The 
IPM/TPM  maintains  the  official  baseline  network  as  well  as  the  other  official 
schedules  such  as  current  and  projected.  No  one  other  than  the  IPM/TPM  can 
change  the  schedules  or  associated  information.  Other  data  required  by  the 
IPM/TPM  is  extracted  from  the  various  stovepipe  systems  and  placed  in  the  project 
database.  The  information  flow  from  the  district  upward  is  shown  in  Fig.  C.2.  The 
requirement  for  detail  will  decrease  as  the  information  flows  upward  as  shown  in 
Fig.  C.3. 

C7.  The  IPM/TPM  utilizing  the  network  schedule  and  associated  information 
prepares  all  reports  required  internal  to  the  district  and  for  submittal  to  higher 
authority.  The  management  of  a  project  should  be  composed  of  estimating, 
planning,  scheduling,  monitoring,  and  control.  For  the  purposes  of  this  study,  these 
tasks  are  defined  in  the  following  paragraphs. 

Project  estimating 

C8.  The  total  cost  of  the  project  consists  of  Engineering  and  Design  (E&D) 
cost  to  get  a  project  to  the  construction  stage  and  the  construction  cost.  E&D  costs 
are  derived  from  the  IPM/TPM  system.  The  construction  cost  would  be  derived 
from  a  program  such  as  CACES  that  will  be  interfaced  with  the  IPM/TPM  system. 
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ASA  REQUIREMENTS 


Figure  C.2  LCPM  information  flow  to  higher  authority 


work  decomposition 


Project  planning 


C9.  The  team  envisions  LCPM  being  executed  by  the  district  offices  who 
then  report  to  LCPM  counterparts  in  the  division  office  and  at  HQUSACE. 
Planning  would  be  initiated  by  the  district  IPM/TPM  by  establishing  a  list  of  basr 
milestones.  The  basic  milestones  would  include  a  standard  set  of  milestones  defined 
by  higher  authority  as  well  as  any  other  deemed  appropriate  by  the  district  or 
IPM/TPM.  The  milestones  would  also  conform  to  a  standard  work  break  down 
structure  as  developed  by  higher  authority.  Planning  continues  with  the  IPM/TPM 
getting  all  affected  organizations  and  disciplines  together  to  identify  major  activities 
that  accomplish  the  milestones  and  assign  responsibilities  to  the  major  activities. 
Target  completion  dates  would  be  established.  This  completes  the  project  planning 
phase  of  LCPM. 

Project  scheduling 

CIO.  Once  the  milestones  and  major  activities  are  fully  developed,  each 
organization  or  discipline  involved  would  break  down  the  major  activities  into  minor 
activities.  The  minor  activities  would  be  to  create  the  cost  accounts.  The  resource 
managers  would  then  break  down  the  minor  activities  into  tasks  for  their  office  (see 
Fig.  C.3).  These  tasks  represent  the  detailed  organization  tasks  (e.g.,  design  task 
drawings).  Resources  would  be  identified  for  each  of  the  tasks. 

Cll.  The  tasks  will  have  start  and  ending  dates  that  fit  within  the  dates  of  the 
minor  activities  but  will  not  necessarily  have  dependencies  between  them.  The  task 
resources  would  be  rolled  up  to  the  minor  activities  which  would  represent  the 
lowest  level  with  required  dependencies.  With  the  resources  assigned,  the  IPM/TPM 
along  with  the  technical  organizations  can  perform  iterations  necessary  to  establish 
baseline  milestone  dates. 

Cl 2.  Once  baselines  arc  established  for  several  or  all  projects  under  LCPM. 
the  LCPM  chief  will  have  the  ability  to  assign  priorities  to  projects  and  compare 
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resource  requirements  against  the  pool  of  available  resources.  This  will  allow  the 
district  to  determine  resource  availability,  identify  shortages,  and  show  detailed 
project  impact  due  to  resource  restrictions.  The  baselines  can  then  be  approved 
from  a  district  perspective  and  used  to  manage,  monitor,  and  evaluate  the  project 
progress.  The  minor  activities  would  form  the  list  of  work  codes  that  need  to  be 
established  in  the  F&A  system  for  cost  accounting  and  project  monitoring. 

Project  monitoring 

03.  The  monitoring  of  project  status  requires  two  perspectives.  The 
IPM/TPM  views  the  project  as  a  whole.  The  resource  manager  views  the  project 
as  one  of  many  projects  the  section  is  to  work  on  over  a  period  of  time.  Tasks  are 
primarily  for  the  resource  manager.  Milestones  and  activities  are  for  the  IPM/TPM. 
Tasks  center  around  the  organizational  break  down  structure,  anu  activities  center 
around  the  work  break  down  structure. 

C14.  The  capability  to  display  the  project  schedule  in  a  bar  chart  format  down 
to  the  lowest  level  which  the  resource  managers  can  use  to  monitor  execution  of  the 
work  should  be  present.  Also,  the  capability  to  sort  the  project  schedule  and 
associated  bar  charts  by  level  of  activities  by  organization  is  desirable. 

Cl 5.  Feedback  of  actual  costs  and  resource  consumption  would  be  provided 
to  the  minor  activities  level.  The  feedback  would  be  placed  in  the  automated 
scheduling  system  to  indicate  actual  progress.  Actual  data  feedback  to  the  tasks  is 
considered  impractical  due  to  the  amount  of  detailed  actual  data  that  must  be  fed 
into  the  COEMIS  F&A,  the  amount  of  tim<™  ’•squired  to  input  such  data,  and  the 
difficulty  in  managing  the  volume  of  data  and  rejects  generated.  The  feedback  to 
the  minor  activities  would  be  made  available  to  all  managers  to  assist  in  evaluating 
progress,  monitoring  utilization  of  resources,  and  tracking  cost  against  the  established 
baseline  for  their  respective  interest. 

C16.  Actual  data  must  be  obtained  from  COEMIS  F&A,  SAACONS.  REMIS, 
ACPF.RS,  etc.  These  would  interface  to  the  IPM/TPM  database  wherein  the  data 
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is  periodically  uploaded  to  the  LCPM  database.  The  IPM/TPM  would  extract  data 
from  the  stovepipe  systems  as  required. 

Project  control 

C17.  For  the  IPM/TPM  to  have  the  ability  to  control  the  progress  of  the 
project,  it  is  necessary  to  have  summary  data  to  the  desired  level.  With  summary 
data,  managers,  at  all  levels,  can  review  progress  against  the  milestones,  major  or 
minor  activities,  or  other  desired  reporting  criteria. 

C18.  Project  control  entails  reassigning  resources  to  activities,  reevaluating 
activity  logic,  and  controlling  changes  to  the  project  scope.  The  control  of  a  project 
is  through  the  management  of  changes  by  both  the  Corps  and  the  contractors. 
Accurate  forecasts  of  how  a  change  affects  project  operation  are  a  by-product  of 
accurate  change  estimates  in  time  and  cost.  The  ability  to  control  cost  would  be 
enhanced  by  increasing  the  use  of  direct  charges  to  the  project  consuming  the  labor 
or  materials  rather  than  relying  on  the  indirect  and  overhead  charge  backs. 
Increased  use  of  direct  charges  would  provide  the  project  manager  with  additional 
cost  information. 

Summary 

C19.  In  summary,  the  IPM/TPM  prepares  an  initial  network  schedule  with 
broad  milestones.  The  IPM/TPM  and  resource  managers  together  develop  the 
major  and  minor  activities.  Resource  managers  develop  tasks  and  identify  the 
required  resources.  Following  several  iterations,  a  baseline  is  established  for  the 
schedule,  resources,  and  cost.  IPM/TPM  utilize  the  milestones,  major  activities,  and 
minor  activities  to  evaluate  progress.  Resource  managers  utilize  tasks  to  manage  the 
execution  of  the  work.  Feedback  of  actuals  to  the  minor  activities  is  furnished  to 
everyone  involved.  All  changes  to  the  schedule,  resources,  and  cost  arc 
documented,  reflected  in  the  network  schedule,  and  included  in  the  project  database. 
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APPENDIX  D  -  LIST  OF  PROJECT  MANAGEMENT 
SYSTEMS  CONSIDERED 


PAC  and  Wings  from  AGS  Management  Systems,  Inc. 

Advanced  Project  Workbench  from  Applied  Business  Technology 
Synergy  from  Bechtel  Software,  Inc. 

ViewPoint  from  Computer  Aided  Management,  Inc. 

SuperProject  Expert  and  CA-Tellaplan  from  Computer  Associates  Inti. 

Plantrac  from  ComputerLine 

Artemis  from  Metier  Management  Systems,  Inc. 

N5500  and  N1100  from  Nichols  &  Company 

PMS-II  from  North  America  MICA 

PMS-80  from  Pinnell  Engineering 

Primavera  Project  Planner  from  Primavera  Systems,  Inc. 

Project/2  and  Quiknet  from  Project  Software  &  Development,  Inc. 
Project  Scheduler/4  from  Scitor  Corp. 

Harvard  Project  Manager  from  Software  Publishing  Corp. 

PROMIS  from  Strategic  Software  Planning,  Inc. 

Timeline  from  Symantec  Corp. 

Vision  from  Systonetics,  Inc. 

Open  Plan  from  Welcom  Software  Technology,  Corp. 
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APPENDIX  E  -  DEMONSTRATION  SCENARIO 
PROVIDED  TO  VENDORS 

When  demonstrating  the  operation  of  the  software,  the  following  features  should  be 
shown  to  exist  and  operate  in  the  presented  software: 

1.  Select  the  beginning  month  of  the  fiscal  year. 

2.  Enter  resource  pool  information  including  resource  identification  with  name, 
total  units  available  by  time,  regular  hourly  rate,  overtime  rate,  organization  code, 
and  code  denoting  hired  labor  or  other  type  resource. 

3.  Enter  dates  in  either  DD/MM/YY,  YY/MM/DD,  or  DD-MMM-YY  format. 

4.  Define  work  week  calendars  that  span  at  least  100  years  with  holidays. 

5.  Create  calendars  for  5-,  6-,  and  7-day  work  weeks  as  a  minimum. 

6.  Create  macros  with  learn  mode  supported. 

7.  Create  reports  in  a  batch  mode. 

8.  Support  either  ADM  or  PDM  or  both. 

9.  Locate  loops  with  Network  algorithm. 

10.  Augment  underlying  database  with  user-defined  fields. 

11.  Create  an  audit  trail. 

12.  Provide  security  of  data  by  assigned  user. 
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13.  Interface  with  a  minicomputer/mainframe  project  management  system. 

14.  Execute  on  a  local  area  network. 

15.  Create  word  processing  documents. 

16.  Define  ES  and  EF  of  zero  duration  activity. 

17.  Support  resource  leveling. 

18.  Project  identification  with  name,  project  manager  name,  project  start  date, 
project  end  date,  date  of  last  update,  baseline  and  revised  baseline  schedule,  and 
user  text  region. 

19.  Activities  with  unique  identification,  description,  duration  in  hours,  days,  weeks, 
or  months,  calendar  used,  hammock  (or  subproject  reference),  ES,  EF,  LS,  LF,  SS 
(TS),  SF  (TF),  FF,  TF,  responsible  organization,  accounting  cost  code,  work  break 
down  structure,  text  to  annotate  activity  information,  and  physical  percent  complete. 

20.  Milestone  with  unique  identification  within  activity,  date  of  milestone,  and 
description. 

21.  Resource  spread  over  time  -  Resource  used  with  unique  identification  within 
activity,  description,  performing  organization  (performing  individual),  duration  with 
incremental  requirement  or  total  requirement  over  life  of  activity  or  total  require¬ 
ment  over  duration,  organization  break  down  structure,  resource  used  to  date,  and 
percent  complete. 

22.  Fixed  resource  regardless  of  time  -  Fixed  cost  (as  in  a  contract)  with  unique 
identification  within  an  activity,  description,  type  of  fixed  cost  (contract,  purchase 
order,  etc.),  date  for  beginning  cash  disbursement,  duration,  total  cost,  obligations 
to  date,  expenditures  to  date,  commitments  to  date,  disbursed  to  date,  and  accrued 
to  date. 
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23.  Reporting  -  Ability  to: 


a.  Customize  the  report  headings. 

b.  Customize  the  standard  reports. 

c.  Perform  ad  hoc  reporting  against  the  stored  data  to  include  user-defined  sort 
and  selection,  subtotals  on  sorted  fields,  report  totals,  detail  reporting,  summary 
reporting,  subtotal  headings  and  footings,  and  intermediate  columns  derived  from 
math  functions  on  project  data. 
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APPENDIX  F  -  SUMMARY  SOFTWARE  REVIEWS 


1.  System  Name:  OPEN  PLAN 

2.  Description:  Open  Plan  is  available  from  Welcom  Software  Technology  and 
runs  on  IBM  compatible  PCs  and  on  the  DEC  VAX  under  VMS.  It  operates  in 
either  the  Arrow  Diagramming  Method  (ADM)  or  the  Precedence  Diagramming 
Method  (PDM).  GSA  Cost  $2,310.00. 

3.  General  Operation:  Open  Plan  operates  from  within  dBase  III+  (or  com¬ 
patibles  FOXBASE+  and  RECITAL  in  the  VAX).  The  program  is  written  in 
dBase  procedure  code  (except  for  the  scheduler  and  query/report  writer)  and  files 
are  stored  in  dBase  format.  This  allows  the  user  to  customize  both  code  and 
database  to  local  requirements.  Other  files  that  are  not  part  of  Open  Plan  may  be 
integrated  into  the  system. 

4.  Data  Entry:  The  system  data  is  entered  through  data  input  screens  which  can 
be  customized,  or  a  graphical  mode  which  allows  the  user  to  see  the  network  logic 
as  it  is  prepared.  Data  is  also  accessible  directly  through  dBase  for  users  who  prefer 
to  bypass  menus  or  execute  ad  hoc  queries. 

5.  Reporting:  Open  Plan  uses  the  reporting  features  available  in  dBase  in  addition 
to  its  own  report  writer.  These  features  allow  for  sophisticated  customization  of 
both  graphical  and  tabular  reports  by  the  user. 

6.  Comments:  Open  Plan  offers  a  great  deal  of  flexibility  in  its  adaptability  to  the 
Corps  environment.  The  dBase  orientation  provides  a  tool  that  can  be  interfaced 
immediately  with  other  district  dBase  applications.  Interfaces  with  other  systems 
can  be  readily  created  through  dBase  and  linked  directly  to  the  scheduling  system. 
Multiproject  scheduling  and  summary  features  are  contained  in  the  system,  but 
unless  it  is  used  in  a  multiuser  environment,  these  features  will  probably  not  be  fully 
utilized.  One  option  that  has  real  potential  is  the  PRISM  import  and  export 
routine. 

7.  Conclusions:  Open  Plan  appears  capable  of  meeting  all  current  LCPM 
management  and  reporting  requirements.  Its  dBase  orientation  means  quick 
acceptance  in  most  district  offices  and  the  ability  to  rapidly  create  interfaces  with 
existing  systems.  The  Chicago  District  has  already  customized  Open  Plan  to  produce 
LCPM  reports. 
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1.  System  Name:  ARTEMIS 


2.  Description:  ARTEMIS  is  a  commercially  available  project  management 
software  program  from  METIER,  a  subsidiary  of  Lockheed.  The  program  runs  on 
IBM  compatible  PCs,  DEC  VAX,  and  IBM  mainframes.  It  operates  in  either  the 
Arrow  Diagramming  Method  (ADM)  or  the  Precedence  Diagramming  Method 
(PDM).  GSA  Cost  $6,000.00  for  PC  version. 

3.  General  Operation:  Artemis  operates  from  within  its  own  relational  database 
system.  The  program  is  written  in  its  own  Artemis  language  which  allows  the  user 
to  customize  both  the  code  and  the  database  to  his  own  requirements.  Other  data 
files  may  be  integrated  into  the  system. 

4.  Data  Entry:  The  system  is  fed  through  user-customized  data  input  screens,  or 
a  graphical  mode  which  allows  the  user  to  see  the  network  logic  as  it  is  prepared. 
Data  is  also  accessible  directly  through  Artemis’  language  for  users  who  prefer  to 
bypass  menus  or  execute  ad  hoc  queries. 

5.  Reporting:  ARTEMIS  uses  the  reporting  features  available  in  its  scheduling 
package  in  addition  to  the  customized  features  available  in  the  Artemis  language  to 
produce  reports.  These  features  allow  for  sophisticated  customization  of  both 
graphical  and  tabular  reports  by  the  user. 

6.  Comments:  The  system  offers  a  great  deal  of  flexibility  in  its  adaptability  to  the 
Corps  environment.  The  Artemis  language  seems  to  have  a  sophisticated  capability 
although  it  is  different  from  systems  currently  in  use  in  the  district  offices.  Inter¬ 
faces  with  other  systems  can  created.  Multiproject  scheduling  and  summary  features 
are  contained  in  the  system,  but  unless  it  is  used  in  a  multiuser  environment,  these 
features  will  probable  not  be  fully  utilized. 

7.  Conclusions:  Artemis  appears  capable  of  meeting  all  current  LCPM  manage¬ 
ment  and  reporting  requirements.  The  database  structure  has  limited  ability  for 
customization. 
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1.  System  Name:  TIMELINE 


2.  Description:  Timeline  is  a  commercially  available  project  management  software 
program  from  Symantec  Corp.  The  program  runs  on  IBM  compatible  PCs.  It 
operates  in  the  Precedence  Diagramming  Method  (PDM).  Cost  $700.00  list,  $350.00 
discounted. 

3.  General  Operation:  The  program  is  written  in  the  Modula-2  language  and 
allows  virtually  no  customization  by  the  user.  It  does  have  a  well-developed  export 
routine  for  sharing  files  with  other  systems.  An  arrangement  with  Artemis  and 
Welcom  Software  has  been  established  to  allow  the  sharing  of  project  data  between 
systems.  There  is  no  mainframe  version  of  Timeline  itself. 

4.  Data  Entry:  The  system  is  fed  through  a  combined  data  input  screen  and  gantt 
chart.  A  useful  feature  of  the  system  allows  the  schedule  to  be  prepared  in  an 
outline  form  according  to  a  work  break  down  structure.  This  allows  the  roll  up  of 
detailed  activity  information  in  a  graphical  manner  that  is  useful  for  managerial  level 
reporting  in  a  simple  format.  Tabular  reporting  of  costs  are  also  rolled  up  based 
on  the  graphical  representation. 

5.  Reporting:  Timeline  has  a  series  of  reports  available.  The  user  can  selectively 
view  desired  information,  but  there  is  no  facility  to  produce  customized  reports  that 
are  not  tabular  displays  of  the  project  data.  A  graphical  representation  of  the 
network  logic  is  available  on  the  screen. 

6.  Comments:  The  system  offers  a  simple  tool  which  could  be  used  at  the  lowest 
levels  of  the  organization  to  produce  schedule  and  limited  resource  information. 
This  could  be  a  cost-effective  tool  since  Timeline  is  generally  available  for  upgrade 
within  most  districts  due  to  its  availability  on  the  Zenith  contract.  Timeline  is  not 
a  database  system  and  does  not  have  any  sophisticated  customization  abilities. 

7.  Conclusions:  Timeline  does  not  appear  capable  of  meeting  current  LCPM 
management  and  reporting  requirements.  There  does  appear  to  be  a  role  for  the 
use  of  Timeline  as  a  feeder  system  tor  a  more  sophisticated  tool.  Data  would  need 
to  be  exported  from  Timeline  into  another  system  for  analysis  of  multiproject 
impacts  and  the  production  of  sophisticated  reports.  This  would  require  that  the 
districts  standardize  on  Precedence  Notation  for  scheduling  projects. 
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1.  System  Name:  SYNERGY 


2.  Description:  Synergy  is  a  commercially  available  project  management  software 
program  from  Bechtel  Software.  The  program  runs  on  IBM  compatible  PCs  and  on 
the  DEC  VAX.  It  is  a  total  environment  system  encompassing  not  only  project 
scheduling,  but  also  accounting,  estimating,  resource  management,  and  other 
modules.  The  project  scheduling  module  is  called  PANORAMA  and  may  be 
operated  in  either  the  Arrow  Diagramming  Method  (ADM)  or  the  Precedence 
Diagramming  Method  (PDM).  Each  of  11  modules  costs  $2,000.  PANORAMA 
costs  $5,000. 

3.  General  Operation:  The  program  operates  from  within  ORACLE.  The 
program  is  written  in  ORACLE  code,  and  the  files  are  stored  in  ORACLE  format. 
This  allows  the  user  to  customize  both  the  code  and  the  database.  Other  files  that 
are  not  part  of  the  system  may  be  integrated  into  the  system.  The  modules  of  the 
system  all  work  together.  Individually,  the  modules  are  less  sophisticated  than  many 
others  available  (the  scheduling  package  has  no  cost  computation  capabilities,  for 
example),  but  the  relationship  between  the  modules  enhances  the  total  package’s 
performance. 

4.  Data  Entry:  The  system  is  fed  through  user-customized  data  input  screens  or 
a  graphical  mode  which  allows  the  user  to  see  the  network  logic  as  it  is  prepared. 

5.  Reporting:  Synergy  uses  the  reporting  features  available  in  its  reporting  module 
in  addition  to  limited  report  preparation  ability  within  PANORAMA.  These 
features  allow  for  sophisticated  customization  of  both  graphical  and  tabular  reports 
by  the  user.  Ad  hoc  reporting  and  customized  reports  can  be  generated  by 
ORACLE  reporting  products. 

6.  Comments:  Synergy  is  not  a  simple  system.  The  system  offers  a  great  deal  of 
flexibility  in  its  adaptability  to  the  Corps  environment.  The  ORACLE  orientation 
provides  a  tool  that  can  be  interfaced  with  the  future  plans  of  the  ISMP  program 
to  convert  the  corporate  database  to  ORACLE.  Currently,  however,  ORACLE  is 
not  in  use  in  quantity  within  the  district  offices.  As  such,  it  would  take  an 
extraordinary  effort  to  field  the  system.  A  system  like  this  could  play  a  part  in  the 
Corps’  long-term  system  needs,  but  current  hardware  availability  problems  (CEAP 
questions)  limit  its  current  utility. 

7.  Conclusions:  Synergy  does  appear  capable  of  meeting  all  current  LCPM 
management  and  reporting  requirements.  The  effort  associated  with  fielding  a 
system  such  as  this  would  certainly  take  in  excess  of  a  year  and  would  involve  a 
dramatic  revision  of  the  current  way  of  doing  business.  This  would  probably  be 
beneficial  to  the  Corps,  but  premature  at  this  time.  When  ORACLE  is  running  in 
the  districts  and  the  systems  are  modernized,  this  system  should  be  reexamined. 
Prior  to  this  product  purchase,  testing  must  be  conducted  at  a  pilot  field  office  test 
site. 
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1.  System  Name:  WINGS 


2.  Description:  Wings  is  one  of  the  project  management  systems  developed  by 
AGS  Management  Systems,  Inc.  The  system  is  available  on  IBM  mainframes,  DEC 
VAX  minicomputers,  and  IBM  PC  and  compatibles.  The  single  user  GSA  price  for 
the  PC  is  $9,500. 

3.  General  Operation:  Since  Wings  is  available  on  mainframes  as  well  as 
microcomputers,  the  PC  version  retains  most  of  the  mainframe  look  and  feel.  The 
system  is  menu  driven.  The  menus  are  constructed  such  that  the  system  can  be 
command  driven  when  the  user  becomes  proficient.  The  product  operates  as  close 
as  possible  on  the  PC  as  on  the  central  computer  installations.  The  underlying 
database  is  proprietary  and  the  user  is  not  allowed  to  change  the  database  structure. 
Customization  is  available  through  the  vendor.  Wings  will  operate  on  a  LAN.  On 
the  LAN,  a  project  can  be  used  by  one  person  at  a  time. 

4.  Data  Entry:  The  data  entry  displays  are  able  to  be  customized  by  the  user. 
Mandatory  entry  fields  must  be  retained  on  the  customized  displays.  The  data  is 
entered  in  the  common  field  by  field  approach.  The  command  level  allows  for  quick 
navigation  of  the  data  entry  displays  rather  than  facilitating  data  entry  into  the 
database.  The  product  supports  a  cost-sharing  approach  to  a  project.  Wings  can 
store  costs  at  the  various  levels  of  the  work  break  down  structure. 

5.  Reporting:  The  reports  provided  by  the  product  contain  limited  graphical 
capabilities.  The  columnar  reports  are  common  to  other  products.  The  reports  are 
basically  templates  that  can  be  applied  to  various  levels  of  reporting  within  the  work 
break  down  structure.  Summarization  and  aggregation  of  data  are  supported  for 
display  of  data  by  various  periods  of  time  within  a  single  report.  This  feature  would 
support  the  current  format  of  project  reporting. 

6.  Comments:  The  product  is  undergoing  development  to  support  full  graphical 
reporting.  The  product  does  not  have  a  clean  mechanism  for  project  change 
tracking  or  resource  time  blocking.  Mulliproject  reporting  is  supported  with 
appropriate  reports  available. 

7.  Conclusions:  The  Wings  product,  with  some  customization,  could  be  used  as  an 
LCPM  tool.  The  currently  supported  platforms  do  not  include  currently  installed 
Corps  hardware.  It  may  be  possible  for  the  product  to  function  on  a  high-speed 
microcomputer  in  a  LAN  environment. 
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1.  System  Name:  Primavera  Project  Planner 


2.  Description:  Project  Planner  is  a  sophisticated  project  monitoring  system  based 
on  the  bTrieve  product  line.  The  underlying  database  is  usable  by  the  rTrieve  and 
the  xTrieve  products.  GSA  Price:  $  1,500.00  (graphics  $900.00  extra). 

3.  General  Operation:  The  system  is  menu  controlled  with  a  batch  operation  if 
desired.  The  menus  are  mainframe  oriented  and  do  not  fully  use  the  capabilities 
of  a  PC.  The  graphical  add-on  is  impressive  and  is  a  definite  asset  to  the  product. 

4.  Data  Entry:  The  data  is  entered  through  fixed  data  entry  displays.  The  menu 
structure  is  shallow  so  the  movement  between  screens  is  tolerable.  The  means  for 
quick  project  planning  and  scheduling  are  not  evident.  The  product  supports  a 
batch  updating  capability  for  input  of  actual  costs. 

5.  Reporting:  The  main  strength  of  Project  Planner  is  the  graphical  capability  of 
the  Primavision  add-on  package.  This  product  truly  provides  presentation  quality 
graphics.  The  graphical  capabilities  exceeded  all  other  reviewed  packages.  Currently 
formatted  LCPM  reports  are  not  readily  offered  in  the  package.  Since  the  software 
uses  the  bTrieve  data  storage  modules,  ad  hoc  reporting  is  theoretically  possible. 
However,  personnel  need  to  be  trained  on  bTrieve  which  is  not  a  common  database 
language.  Several  districts  are  currently  using  the  Primavera  products  for  LCPM. 

6.  Comments:  Project  Planner  is  a  menu-controlled  system  with  no  export 
capability.  The  user  interface  will  require  training  as  the  required  entry  is  not 
always  self-evident.  The  full  project  management  suite  of  products  would  include 
Project  Planner,  Parade,  and  Finest  Hour  (for  hourly  scheduling).  Integration  on 
the  PC  is  through  a  vendor-supplied  menu  system.  Multiple  project  linking  is  by  a 
merge  capability.  This  would  increase  the  required  disk  capacity  if  many  merges 
were  required.  Merged  projects  would  tend  to  be  those  that  were  enormous  in 
scope.  The  reports  allow  for  the  comparison  of  two  schedules  at  a  time. 

7.  Conclusions:  This  product  supports  most  of  the  criteria  requested  by  the  team. 
The  graphics  are  impressive.  However,  the  system  is  somewhat  inflexible  for 
developing  customized  reports. 
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1.  System  Name:  PRISM 


2.  Description:  PRISM  is  a  USACE-wide  project  and  resource  scheduling  system 
utilizing  the  Arrow  Diagramming  Method  (ADM)  that  runs  on  Honeywell  computers 
at  the  divisions.  The  system  allows  for  the  scheduling  of  all  projects  (civil  and 
military).  The  system  interfaces  with  other  COEMIS  elements  (personnel  and  F&A 
most  significantly)  and  is  designed  to  compute  resource  requirements  for  individual 
projects  as  well  as  assessing  the  impact  of  the  entire  district’s  work  load  on  the 
capabilities  of  the  district.  The  system  was  designed  and  maintained  by  the 
Programs  Management  offices,  and  the  primary  focus  has  been  on  the  ability  to 
summarize  information  for  upward  reporting  purposes. 

3.  General  Operation:  The  system  is  menu  driven  with  remote  communications  to 
a  Honeywell  computer  running  in  ASCII  character/line  mode  transmission.  Reports 
are  batch  oriented.  The  database  is  in  DM-IV,  and  the  application  is  written  in 
DM-IV  TP  and  Cobol. 

4.  Data  Entry:  The  system  is  fed  through  an  on-line  interactive  system  located  on 
the  division  Honeywell.  The  user  normally  logs  on  to  a  TAB- 132  terminal  and  is 
guided  through  a  series  of  menus  to  a  data  input  screen.  This  is  a  very  slow  and 
laborious  process  due  to  both  system  design  and  hardware  restrictions.  Proper 
coding  of  activity  information  allows  the  system  to  access  other  data  systems  (e.g., 
actual  costs  from  the  F&A  database)  and  to  perform  a  network  analysis  to 
determine  activity  start  and  finish  dates.  Once  the  data  has  been  input,  other  menu 
options  allow  the  user  to  compute  the  costs  of  activities,  determine  the  project 
schedule,  and  produce  reports.  A  PC-based  package  written  in  micro-focus  Cobol 
is  under  development  which  allows  the  project  manager  to  extract  project 
information  to  the  PC  for  data  entry  and  then  reload  it  in  a  batch  mode  for 
processing.  Many  of  the  reports  that  the  district  Programs  Management  offices  are 
required  to  maintain  and  forward  to  HQUSACE  are  intended  to  be  extracted 
automatically  from  the  PRISM  database. 

5.  Reporting:  Reporting  is  limited  to  the  standard  reports,  locally  developed 
reports,  and  ad  hoc  reporting  through  the  LOUIS  query  system. 

6.  Comments:  The  system  is  "user  hostile."  The  speed  of  response  and  the  time 
required  to  enter  and  update  the  data  have  eliminated  the  potential  benefit  to  the 
project  manager.  There  is  no  current  documentation  for  the  user  to  read  when  a 
problem  is  encountered.  Menu  selections  do  not  work.  Reports,  which  cannot  be 
run  from  the  menu,  require  that  the  user  exit  the  system  and  run  the  report  from 
the  Honeywell’s  Job  Control  Language.  The  system  also  has  no  ability  to  produce 
a  network  logic  diagram,  a  critical  tool  for  the  project  manager.  The  system’s 
orientation  has  been  toward  roll-up  and  upward  reporting  of  information  at  the 
expense  of  the  project  manager  who  is  charged  with  maintaining  the  data.  PC- 
based  systems  have  shown  project  managers  that  the  tools  available  commercially  are 
much  better  at  meeting  their  needs  than  PRISM  and  that  PRISM  docs  not  have  the 
ability  to  accept  data  generated  in  other  systems. 
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7.  Conclusions:  PC-based  systems  are  generally  oriented  around  a  single  or  small 
number  of  projects  (the  PC  is  nominally  a  single  user  environment).  The  abilities 
to  look  at  the  effects  of  multiple  concurrent  projects  on  the  district  as  a  whole,  to 
level  the  district’s  resources  over  multiple  projects,  and  to  interface  directly  with  the 
F&A  system  are  features  that  are  easier  to  manage  in  a  mainframe  environment. 
PRISM  could  be  revised  to  allow  the  manager  to  do  the  schedule  input  on  the  PC 
with  a  commercial  scheduling  package,  export  the  information  to  PRISM  for 
resource  leveling  and  cross  project  summary  information  (to  include  LCPM 
reporting),  and  then  extract  the  information  back  to  the  PC  for  the  project 
manager’s  use.  This  approach  is  workable  with  current  hardware  but  would  require 
software  changes. 
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1.  System  Name:  AMPRS 


2.  Description:  AMPRS  is  a  USACE-wide  database  that  runs  on  the  Honeywell 
computers  at  the  divisions  and  at  EASA  The  database  is  made  up  of  selected 
information  on  all  projects  (both  civil  and  military)  which  will  ultimately  go  into 
construction.  Projects  are  added  to  the  database  at  the  time  that  the  decision  is 
made  to  go  ahead  with  the  project  (usually  after  the  feasibility  or  letter  report). 
The  data  stored  in  the  files  consist  of  key  dates  for  the  project,  cost  projections, 
general  project  data  (location,  project  manager,  contractor,  etc.),  and  a  listing  of 
modifications  to  the  construction  contract.  Local  districts  have  the  option  of  adding 
new  fields  to  the  system  for  local  use  in  addition  to  those  fields  required  in  upward 
reporting. 

3.  General  Operation:  AMPRS  requires  a  PC,  the  Division  Honeywell  computer, 
and  communication  with  EASA  The  system  design  is  concentrated  in  the  reporting 
of  construction  project  data. 

4.  Data  Entry:  The  system  is  fed  through  a  PC-based  package  written  in  micro¬ 
focus  Cobol  called  AMUS  which  provides  a  menu-driven  routine  through  which  the 
user  can  enter  data  which  is  batch  loaded  onto  the  Honeywell.  This  data  is  then 
extracted  back  to  the  PC  in  ASCII  format  and  transferred  via  modem  to  the 
Honeywell  at  EASA  where  it  is  merged  and  made  available  for  Corps-wide  analysis 
and  HQUSACE  information.  This  is  done  on  a  monthly  basis. 

5.  Reporting:  Reporting  is  limited  to  the  standard  reports  and  locally  developed 
reports. 

6.  Comments:  The  system  advertises  itself  as  the  "official"  Corps  of  Engineers 
information  system.  Management  has  generally  ignored  it  and  asked  for  similar 
information  to  be  produced  manually  (witness  the  LCPM  reports).  It  is  seen  as  an 
unrewarded  exercise  by  most  of  the  people  who  are  required  to  contribute  to  the 
system.  The  system  has  no  network  scheduling  abilities;  it  is  strictly  a  database. 
The  schedule  derived  information  contained  in  the  database  must  be  produced 
elsewhere  and  retyped  into  the  database. 

7.  Conclusions:  The  manual  reporting  requirements  are  largely  unworkable.  A 
database  system  which  contains  the  information  from  which  HQUSACE  could 
extract  information  of  interest  would  be  a  convenient  solution  to  this  problem.  The 
AMPRS  data  could  be  revised  to  reflect  the  report  requirements  (other  data  would 
be  eliminated).  Project  managers  would  manage  their  schedules  on  PC-based 
systems  and  then  extract  and  summarize  the  data  in  a  format  which  could  be  batch 
loaded  into  AMPRS.  Care  must  be  taken  in  this  approach  to  ensure  that  the 
information  requested  can  be  produced  from  network  data. 
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